MySQL 8.0中覆盖索引无法优化Limit查询的疑问

我来拆解一下你遇到的问题，核心原因和MySQL优化器的成本判断、索引结构以及子查询的执行逻辑有关，咱们一步步说清楚：

1. 子查询的索引利用逻辑先理清楚 #

你的子查询是：

select film_id from sakila.film b order by title limit 50,5

按照覆盖索引的思路，sakila.film默认有idx_title（title字段的二级索引），而InnoDB的二级索引叶子节点会自带主键film_id，理论上这个子查询完全可以直接通过idx_title索引获取排序后的film_id，不需要扫描全表。

那为什么EXPLAIN显示扫描了1000行？这大概率是MySQL优化器的成本选择在起作用：

• sakila.film只有1000行，属于极小表。优化器会对比两种执行方式的成本：
  • 走idx_title索引：需要遍历索引树定位到第55行（跳过50取5），再提取film_id，涉及多次随机IO。
  • 全表扫描+内存排序：直接顺序读取全表数据，在内存里完成排序后取目标行，顺序IO的成本更低。
• 对于小表来说，优化器会认为全表扫描的整体成本更低，所以自动选择了这个方案，导致你看到扫描行数是1000。

2. 验证方法：强制让索引生效 #

你可以给子查询加上FORCE INDEX，强制优化器使用idx_title索引，再看执行计划的变化：

SELECT a.film_id, a.description 
from sakila.film a 
inner join ( 
  select film_id from sakila.film b FORCE INDEX(idx_title) order by title limit 50,5 
) as lim USING(film_id)

这时候再用EXPLAIN分析子查询部分，应该会看到扫描行数大幅减少（比如55行左右）——这说明你的覆盖索引思路本身是对的，只是优化器默认选了更“划算”的全表扫描。

3. 额外补充：主查询的回表问题 #

另外，主查询里你需要获取description字段，这个字段不在任何索引中，所以主表关联时必须回表读取这部分数据，但这和子查询的扫描行数无关——子查询的覆盖索引优化是针对自身的，主查询的回表是不可避免的（除非把description也加到联合索引里，但这样索引体积会暴增，完全没必要）。

总结 #

你的覆盖索引优化思路本身没问题，只是因为表数据量太小，MySQL优化器选择了成本更低的全表扫描。如果换成数据量更大的表（比如几万行以上），优化器会自动选择走索引，此时覆盖索引的优化效果就会明显体现出来。

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