为什么带有子查询的 MySQL LIMIT 条件搜索比简单搜索更快？答案

【问题标题】：Why MySQL LIMIT condition search with subquery is faster than simple search?为什么带有子查询的 MySQL LIMIT 条件搜索比简单搜索更快？
【发布时间】：2017-02-14 06:38:00
【问题描述】：

在阿里巴巴Java代码约定中提到，参见https://yq.aliyun.com/articles/69327Rule 3.2.7

SELECT a.* FROM table1 a, (SELECT id FROM table1 WHERE condition LIMIT 100000, 20) b WHERE a.id = b.id

比

快很多

SELECT * FROM table1 WHERE condition LIMIT 100000, 20

本文解释了 MySQL 将获取 100020 个结果行并消除前 100000 个而不是仅获取 20 行。

在 MySQL 查询引擎中是真的吗？可能是错误或缺陷？

更新

假设 table1 包含 MANY 列（10+）并且条件不太复杂（例如ip LIKE '192.168.%'）

【问题讨论】：

并非总是如此。这取决于出现在condition 中的字段是否被索引（以及它们如何被索引以及它们在condition 中如何使用）。
并取决于选择了多少列，刚刚测试过:-)
其实，如果condition包含不在任何索引中的列，两种情况下MySQL都会强制从表数据中读取100020行。从理论上讲，这种情况会使第一次查询变得更糟（因为它必须读取表数据两次），但实际上，缓存（内部 MySQL 缓存和文件系统缓存）很可能会阻止它变成灾难。
您按什么顺序测试了查询？你先执行第二个吗？
@auntyellow N.B 在上面的问题中有一点。 MySQL 保留一个内部缓存，如果您按顺序运行两个查询，则第二个查询很可能使用已经在缓存中的数据（它运行得更快，但查询本身对速度没有任何贡献）。

标签： mysql subquery limit

【解决方案1】：

是的，这是真的。

第一个查询仅扫描 100020 个结果行以查找字段 id，然后扫描 20 行完整字段，但第二个查询扫描 100020 个字段。

【讨论】：

“但第二个查询扫描 100020 的所有字段”——这并不完全正确。这取决于condition中出现的字段和表的索引。
@axiac：在我的陈述中，我假设前 100020 行的 where 条件为真。