SQL Query 上聚集索引的性能答案

【问题标题】：Performance of clustered index on SQL QuerySQL Query 上聚集索引的性能
【发布时间】：2015-12-12 06:12:44
【问题描述】：

假设你有两个表：

Student(id, class) // 100 rows
Course(id, course) // 100 rows

最初假设两个表上都没有索引。现在假设我们有一个查询：-

select id, course 
from Student join course 
on student.id = Course.id and student.id = 20

由于你没有任何索引，所以你需要遍历两个表中的所有行。

Time complexity - O(100 x 100)

现在我们更新了表，Student.id 是主键。将在其上创建聚集索引，现在整体复杂度为

Time complexity - O(log 100) // Nested loop join

你认为我的假设是正确的吗？有人可以帮我吗？

嵌套循环连接算法在这里：

【问题讨论】：

我认为你不应该混合join + where。 select id, course from Student join Course ON student.id = Course.id WHERE student.id = 20
请不要使用这种过时的连接语法。它可以工作，但 SQL 标准为此提供了 JOIN .. ON...。

【解决方案1】：

join course 
on student.id = Course.id

在O(MN)（最坏情况）中是正确的，其中M 和N 分别是第一个和第二个表中的行数，因为那是equi-join（加入=条件）它将第一行的每一行与第二行进行比较。

但是，您还有第二个条件。由于SQL 有许多性能增强算法，很可能首先评估student.id = 20。然后你首先需要M（假设学生表的行数是线性的）来搜索student.id = 20。然后，如果student.id = 20 只是常数，假设是 m，那么您将拥有m * N。

总之，O(M + (m * N))。

这取决于m。如果m 是常数，那么在渐近分析O(M + N) = O(2M) 中，因为M=N 最终得到O(M) = O(N) 或线性。否则，如果m 在Omega(1) 中，那么它将是O(M + M * N) 或您假设的O(MN)。

然后对于PRIMARY KEY，将/可以创建一个聚集索引。现在未来查询的时间复杂度将如您所说O(log K)，其中 K 是新表中的行（可以是！= 100）。

现在为什么要log K？因为关系数据库将索引构造为B-trees。然后在 WC 你在树的高度得到O(log K)。

更准确

因为在 B 树上你有最大值。 2d children 和 s 之间的键数 d - 1 < s < 2d。 d 称为树的阶数、度数或分支因子。

希望对你有帮助！

【讨论】：