由于您无法控制所选的算法，因此无法直接知道。但是，没有索引的SELECT应该为O（n）（表扫描必须检查每条记录，这意味着它将根据表的大小进行缩放）。

使用索引时，SELECT可能为O（log（n））（尽管如果适用于任何实表，则SELECT取决于用于索引的算法以及数据本身的属性）。为了确定任何表或查询的结果，您必须求助于对真实世界数据进行概要分析。

不带索引的INSERT应该非常快（接近O（1）），而UPDATE需要首先找到记录，因此，它会比使您到达那里的SELECT慢（略）。

当索引树需要重新平衡时，带有索引的INSERT可能会再次处于O（log（n ^
2））的范围之内，否则将更接近O（log（n））。如果它影响SELECTED成本之外的索引行，则UPDATE也会发生相同的速度下降。

一旦您谈到混合中的JOIN，所有的赌注都关闭了：您将必须分析并使用数据库查询估计工具来进行阅读。还要注意，如果此查询对性能至关重要，则应不时 重新
配置，因为查询优化器使用的算法会随着数据负载的变化而变化。

要记住的另一件事… big-
O不会告诉您每笔交易的固定成本。对于较小的桌子，这些费用可能会高于实际工作成本。举个例子：单行跨网络查询的建立，删除和通信成本肯定会比在小表中查找索引记录更多。

因此，我发现能够将一组相关查询捆绑在一起可以比我对数据库进行的任何优化对性能的影响大得多。