对于包含n
行并且我想要返回m
结果的表格,SQL选择的Big-O是什么?
Update
,delete
或Create
操作的Big-O是什么?
我说的是一般的mysql和sqlite。
答案 0 :(得分:41)
由于您无法控制所选的算法,因此无法直接了解。但是,没有索引,SELECT应该是O(n)(表扫描必须检查每个记录,这意味着它将按照表的大小进行缩放)。
对于索引,SELECT可能是O(log(n))(尽管它取决于用于索引的算法和数据本身的属性,如果对于任何真实表都适用)。要确定任何表或查询的结果,您必须求助于分析真实世界数据。
没有索引的INSERT应该非常快(接近O(1)),而UPDATE需要首先找到记录,因此比得到你的SELECT更慢(稍微)。
当索引树需要重新平衡时,带索引的INSERT可能会再次出现在O(log(n ^ 2))的球场中,否则更接近于O(log(n))。如果UPDATE在SELECT成本之上影响索引行,则会发生相同的减速。
一旦你谈到混合中的JOIN,所有的赌注都会被取消:你必须分析并使用你的数据库查询估算工具来阅读它。另请注意,如果此查询对性能至关重要,则应不时重新配置文件,因为查询优化程序使用的算法会随着数据负载的变化而更改。
要记住的另一件事... big-O并没有告诉您每笔交易的固定成本。对于较小的表,这些可能高于实际工作成本。例如:单行的跨网络查询的设置,拆除和通信成本肯定会超过在小表中查找索引记录。
正因为如此,我发现能够在一个批处理中捆绑一组相关查询对性能的影响远远大于我对数据库所做的任何优化。
答案 1 :(得分:1)
我认为真正的答案只能根据具体情况确定(数据库引擎,表格设计,索引等)。
但是,如果您是MS SQL Server用户,则可以熟悉查询分析器(2000)或Management Studio(2005+)中的估计执行计划。这为您提供了大量可用于分析的信息。
答案 2 :(得分:0)
所有这些都取决于您编写SQL的方式(以及您的数据库为您正在执行的操作设计的程度)。尝试使用explain plan函数来查看db将如何执行。的。你可以计算出大O