连接的索引列答案

【问题标题】：Indexing columns for joins连接的索引列
【发布时间】：2013-03-11 21:54:30
【问题描述】：

当我们在属性上创建索引时，我们会更快地找到记录，因为索引是一棵树，并且我们会浏览按排序顺序排列的值。
例如。对于 SELECT * from branches where name='Washington 通过索引，我们将按字典顺序导航以到达日志时间的记录。
但是，当我们对连接中使用的列进行索引时，这是如何工作的呢？
例如。

SELECT BILLS.NAME NAME, BILLS.AMOUNT AMOUNT FROM BILLS,BANK_ACCOUNTS WHERE BILLS.ACCOUNT_ID = BANK_ACCOUNTS.ACCOUNT_ID

如果我们为BILLS(ACCOUNT_ID) 和BANK_ACCOUNTS(ACCOUNT_ID) 创建了一个索引，那么导航如何更快？我们只取BANK_ACCOUNTS.ACCOUNT_ID 的每个值并使用BILLS 的索引树来查找匹配记录？
如果这是它的工作原理，那么为什么人们通常建议在连接中使用的列中创建索引。
在我看来，只创建了 1 个索引，这将用于相等比较器左侧的表，即BILLS。还是我错了？

【问题讨论】：

你应该阅读all of this - 特别是加入操作部分。

标签： mysql sql performance join indexing

【解决方案1】：

您提供的示例代码在 BILLS 和 BANK_ACCOUNTS 之间执行 INNER JOIN，因此只会返回 BILLS 中存在于 BANK_ACCOUNTS 中的行。这是在查询运行时通过仅对 BANK_ACCOUNTS 上的非聚集索引执行连接来检查的，因为查询引用的来自 BANK_ACCOUNTS 的所有字段（即 BANK_ACCOUNTS.ACCOUNT_ID）都是索引的一部分，因此“被覆盖” “ 通过它。

在索引中查找 BANK_ACCOUNTS.ACCOUNT_ID 是 O(log N)，而每次查找扫描 BANK_ACCOUNTS 是 O(N)。

这有帮助吗？

【讨论】：

不确定。performing the join only to the non-clustered index on BANK_ACCOUNTS这意味着它忽略了表，只对索引进行连接？
@Cratylus：是的，这就是索引“覆盖”查询的含义。也就是说，当读取索引记录提供查询所需的所有字段时，引擎知道不会浪费循环从聚集索引中读取完整记录。