MySQL8.0中LIMIT查询添加ORDER BY后执行计划扫描行数差异咨询

首先明确InnoDB引擎的索引存储特性：所有二级索引的叶子节点都会存储对应行的主键值，本次查询仅需要返回id字段，走uniq_show_id索引时不需要回表读取整行数据，属于覆盖索引查询，查询成本极低。

第一条SQL的执行逻辑 #

EXPLAIN SELECT id FROM tb_user WHERE id > 125 LIMIT 10;

过滤条件id>125直接命中主键索引，主键本身按id值有序排列，所以优化器选择主键range扫描方案。EXPLAIN返回的110328行是优化器预估的所有符合id>125条件的总行数，实际执行时因为有LIMIT 10限制，读取到10条符合条件的记录就会终止，不会真的扫描全部11万行。

第二条SQL的执行逻辑 #

EXPLAIN SELECT id FROM tb_user WHERE id > 125 ORDER BY uniq_show_id LIMIT 10;

新增ORDER BY uniq_show_id子句后，优化器需要权衡两种可选方案的执行成本：

• 方案1：继续走主键索引：先取出全部11万条符合id>125的记录，再对所有记录做排序操作，最后取前10条。该方案需要对十万级数据做排序，CPU和内存开销极高，甚至可能触发磁盘临时文件排序，整体成本非常高。
• 方案2：走uniq_show_id唯一索引：该索引本身已经按uniq_show_id值升序排列，完全匹配排序需求。优化器可以顺着索引顺序逐个扫描记录，每次取出索引节点存储的id值判断是否满足id>125的条件，累计找到10条符合条件的记录就可以直接终止扫描。
  根据表数据分布，符合id>125的记录占总记录数的比例约为50%，优化器预估仅需要扫描20条记录就能找到10条符合要求的结果，不需要额外排序，整体成本远低于方案1，因此最终选择了该执行计划。

这是MySQL优化器针对ORDER BY ... LIMIT N场景的典型优化逻辑：当N取值较小时，优先选择能避免排序的索引，哪怕需要过滤部分不符合条件的记录，整体执行成本也远低于大量数据排序的成本。

内容的提问来源于stack exchange，提问作者normal_guy