使用不使用INDEX的查询变量进行SELECT

Question

我正在玩(出于兴趣)在一个简单的邻接列表中检索一个节点树,并使用局部变量进行递归查询.

我到目前为止的解决方案很有趣但我不知道(这是我唯一的问题)为什么MySQL拒绝使用任何INDEX优化此查询.MySQL不能使用INDEX？查找最近的子节点吗？

我很好奇为什么MySQL没有.即使我使用FORCE INDEX执行计划也没有改变.

这是到目前为止的查询,它5是父节点的ID:

SELECT 
  @last_id := id AS id,
  parent_id,
  name,
  @depth := IF(parent_id = 5, 1, @depth + 1) AS depth
FROM 
  tree FORCE INDEX (index_parent_id, PRIMARY, index_both),
  (SELECT @last_id := 5, @depth := -1) vars
WHERE id = 5 OR parent_id = @last_id OR parent_id = 5

试试SQLfiddle的实例

请注意,原因不能是小数据集,因为当我指定FORCE INDEX (id)或FORCE INDEX (parent_id)或FORCE INDEX (id, parent_id)... 时行为不会改变

文档说:

您还可以使用FORCE INDEX,其作用类似于USE INDEX(index_list),但另外还假设表扫描非常昂贵.换句话说,只有在无法使用某个给定索引查找表中的行时才使用表扫描.

必须有一些东西使查询无法使用INDEX,但我不明白它是什么.

---

免责声明:我知道在SQL中存储和检索分层数据有不同的方法.我知道嵌套集模型.我不是在寻找替代实现.我不是在寻找嵌套集.

我也知道查询本身就是坚果并产生错误的结果.

我只是想(详细地)了解MySQL INDEX在这种情况下不使用的原因.

Answer 1

原因在于WHERE子句中使用OR条件。

为了说明这一点，请尝试再次运行查询，这次仅使用条件id = 5，并获取（EXPLAIN 输出）：

+----+-------------+------------+--------+--------------------+---------+---------+-------+------+----------------+
| id | select_type | table      | type   | possible_keys      | key     | key_len | ref   | rows | Extra          |
+----+-------------+------------+--------+--------------------+---------+---------+-------+------+----------------+
|  1 | PRIMARY     | <derived2> | system | NULL               | NULL    | NULL    | NULL  |    1 |                |
|  1 | PRIMARY     | tree       | const  | PRIMARY,index_both | PRIMARY | 4       | const |    1 |                |
|  2 | DERIVED     | NULL       | NULL   | NULL               | NULL    | NULL    | NULL  | NULL | No tables used |
+----+-------------+------------+--------+--------------------+---------+---------+-------+------+----------------+

再次，这次只有条件parent_id = @last_id OR parent_id = 5，并得到：

+----+-------------+------------+--------+-----------------+------+---------+------+------+----------------+
| id | select_type | table      | type   | possible_keys   | key  | key_len | ref  | rows | Extra          |
+----+-------------+------------+--------+-----------------+------+---------+------+------+----------------+
|  1 | PRIMARY     | <derived2> | system | NULL            | NULL | NULL    | NULL |    1 |                |
|  1 | PRIMARY     | tree       | ALL    | index_parent_id | NULL | NULL    | NULL |   10 | Using where    |
|  2 | DERIVED     | NULL       | NULL   | NULL            | NULL | NULL    | NULL | NULL | No tables used |
+----+-------------+------------+--------+-----------------+------+---------+------+------+----------------+

MySQL 不太擅长处理同一查询中的多个索引。AND 条件的情况稍微好一些；人们更有可能看到index_merge优化而不是index union优化。

随着版本的进步，情况正在改善，但我已经测试了您对 version 的查询5.5，这是当前最新的生产版本，结果如​​您所描述的那样。

要解释为什么这很困难，请考虑：两个不同的索引将回答查询的两个不同条件。一个将回答id = 5，另一个回答（顺便说一句，后者中的ORparent_id = @last_id OR parent_id = 5没有问题，因为这两个术语都是在同一索引内处理的）。

没有一个索引可以同时回答这两个问题，因此该FORCE INDEX指令被忽略。看吧，FORCE INDEXMySQL 必须在表扫描上使用索引。这并不意味着它必须在表扫描中使用多个索引。

所以MySQL遵循这里文档的规则。但为什么这么复杂呢？因为要使用两个索引来回答，MySQL 必须从两个索引收集结果，将其中一个存储在某个临时缓冲区中，同时管理第二个索引。然后必须遍历该缓冲区以过滤掉相同的行（某些行可能适合所有条件）。然后扫描该缓冲区以返回结果。

但是等等，该缓冲区本身没有索引。过滤重复项并不是一项显而易见的任务。因此，MySQL 更喜欢在原始表上工作并进行扫描，从而避免所有混乱。

当然这是可以解决的。Oracle的工程师可能还会对此进行改进（最近他们一直在努力改进查询执行计划），但我不知道这是否是在TODO任务上，或者是否具有高优先级。