MySQL 如何遍历复合 B-tree 索引以进行 IN() AND IN() 搜索答案

【问题标题】：How does MySQL traverse a composite B-tree index for IN() AND IN() searchesMySQL 如何遍历复合 B-tree 索引以进行 IN() AND IN() 搜索
【发布时间】：2012-03-23 00:56:52
【问题描述】：

我一直在研究索引，无法完全理解 MYSQL 是如何将索引用于诸如

之类的语句的

IN() AND IN() ... AND IN()

我正在阅读的这本书表明，当我们有一个索引（a，b，...）但用户想要搜索 b 并且我们在 a 中的基数较低时，我们可以使用技巧并简单地添加 IN()

WHERE a IN ('x1', 'x2', ... 'all possible values go here') AND `b`>123

假设我们有以下数据

它如何遍历这棵树来满足上面的查询？它会简单地为 IN-s 创建所有可能的组合，并且会为每个查询几乎遍历树吗？

WHERE `a`='x1' AND `b`>123
WHERE `a`='x2' AND `b`>123
...

因此，由于随着 IN 数量的增加，所有可能的 IN 组合的数量急剧增加，因此我们必须为每个组合运行 B 树？如果上述情况属实，这是否意味着存在某种理论上的观点，即使用 IN 欺骗索引会比完全不使用索引要慢？

【问题讨论】：

标签： mysql indexing b-tree b-tree-index

【解决方案1】：

它合并了几遍的结果。所以是的，你的假设是正确的。 :)

见http://dev.mysql.com/doc/refman/5.0/en/index-merge-optimization.html

在索引合并之前，mysql 无法满足来自索引的此类查询。

【讨论】：

【解决方案2】：

你是对的。

MySQL 对这种类型的 IN 优化使用与执行 JOIN 时相同的技术，并且 MySQL 能够进行大量 JOIN，而不会显着影响性能。

虽然成本最终会达到显着的程度，但与根本不使用索引相比，它通常仍然是一个优势。

根本不使用索引只有在您返回大部分行时才有优势。 MySQL 能够决定何时放弃索引。

【讨论】：