利用“延迟关联”优化 MySQL 巨量数据的深分页查询

1. 简单 LIMIT 的性能瓶颈

假设我们有一张用户画像表 PROFILES，包含以下字段：id (主键), sex, rating, bio (长文本), address 等。我们需要查询性别为男且按评分排序的第 10,001 页数据（每页 10 条）。

普通查询 SQL：

sql 复制代码

SELECT id, sex, rating, bio, address 
FROM PROFILES 
WHERE sex = 'M' 
ORDER BY rating 
LIMIT 100000, 10;

执行原理与问题：

全行扫描 ：即便在 (sex, rating) 上有索引，MySQL 引擎仍需从索引中定位到满足条件的记录，然后根据主键 ID 回表读取整行数据（包含 bio, address 等大字段）。
无效 I/O：MySQL 会扫描并读取前 100,010 行的所有字段，然后抛弃前 100,000 行，只返回最后 10 行。
资源浪费：读取这 10 万行大字段数据产生了巨大的磁盘 I/O 开销，并挤占了 Buffer Pool 缓存空间。

2. 为什么要使用延迟关联？

延迟关联 的核心思想是：先在索引中完成范围扫描和过滤，只获取主键 ID，最后再通过主键关联回原表获取需要的全部列。

优化后的 SQL：

sql 复制代码

SELECT p.id, p.sex, p.rating, p.bio, p.address
FROM PROFILES AS p
INNER JOIN (
    SELECT id 
    FROM PROFILES 
    WHERE sex = 'M' 
    ORDER BY rating 
    LIMIT 100000, 10
) AS x USING(id);

性能提升的原因：

利用覆盖索引 ：内部子查询 x 只查询 id。如果存在合适的联合索引，MySQL 可以在索引树上完成过滤和排序，无需回表。
最小化回表次数 ：在子查询中，MySQL 依然要扫描 100,010 条记录，但此时只操作索引块，不触碰数据页。只有最终胜出的 10 条记录才会执行回表操作获取 bio 等字段。

3. 延迟关联与联合索引的协同效应

延迟关联的威力大小，直接取决于联合索引的设计。

场景 A：无合适联合索引

如果只给 sex 加了索引，子查询执行 ORDER BY rating 时，由于索引中不包含 rating 的有序信息，系统会触发 Using filesort。此时虽然减少了回表，但内存排序的压力依然巨大。

场景 B：存在联合索引 `(sex, rating)`

这是延迟关联的最佳实践：

索引扫描排序 ：子查询进入索引树，由于索引先按 sex 排序，在 sex='M' 的局部块内，rating 已经是物理有序的。
零 Filesort：MySQL 顺着索引链表直接数到第 100,000 个节点，取 10 个 ID 即可。