延迟关联是绕过MySQL“必须扫完offset行”限制的有效策略，需满足索引结构、字段选择和JOIN方式三前提；子查询仅查id可快10万倍，因覆盖索引避免回表随机IO，而主键JOIN实现O(log n)精准查找。
延迟关联不是语法糖，而是绕过MySQL执行器“必须扫完offset行”这一硬限制的务实策略。它有效，但必须满足索引结构、字段选择和JOIN方式三个前提，否则反而更慢。
为什么子查询只查id就能快10万倍？
关键在覆盖索引和回表开销的差异：MySQL执行LIMIT 900000, 10时，并不会跳过前90万行，而是老老实实从索引头开始扫描，每行都判断是否满足WHERE、是否进入排序集、是否该丢弃——哪怕最终只返回10条。
- 原始查询走
idx_status_time（status, transaction_time），但SELECT * 需要回表取account_no、remark等字段，每跳过一行都可能触发一次随机IO - 延迟关联把动作拆成两步：子查询用
SELECT id FROM ... ORDER BY transaction_time DESC LIMIT 900000, 10，只要这个子查询能走覆盖索引（比如INDEX(status, transaction_time, id)），就全程只读索引页，不回表 - 外层
JOIN用主键id精准定位，InnoDB聚簇索引下这是O(log n)的B+树查找，且只查10次
INNER JOIN子查询写法里最容易翻车的3个点
很多同学照着示例改了SQL，结果EXPLAIN显示type: ALL或rows没降下来，问题往往出在这几个细节：
- 子查询里不能出现
SELECT *或任何非索引字段，哪怕只是SELECT id, status——只要status不在索引末尾，优化器就可能放弃覆盖索引 - 复合索引顺序必须严格匹配查询逻辑：
WHERE status = 1 ORDER BY transaction_time DESC，对应索引就得是INDEX(status, transaction_time, id)；把id放前面或中间，子查询就无法跳过排序直接定位 -
ON t1.id = t2.id必须是等值连接，不能写成IN或>=，MySQL 5.7+对非等值JOIN会退化为全表扫描，尤其当t2结果集小但t1巨大时
当ORDER BY字段有重复值，id必须参与排序
如果只按transaction_time DESC排序，而多条记录时间戳相同，MySQL无法保证分页结果的确定性：同一偏移量下，两次查询可能返回不同行，导致翻页错乱或漏数据。
- 正确做法是在ORDER BY中加入主键作为第二排序字段：
ORDER BY transaction_time DESC, id DESC - 对应索引也要扩展为
INDEX(status, transaction_time, id)，确保子查询能稳定、可复现地选出那10个id - 如果业务允许，更推荐游标分页（
WHERE transaction_time ），它天然规避了偏移量跳跃问题，但要求前端保存上一页末尾的完整排序键
延迟关联真正的门槛不在SQL怎么写，而在你是否清楚当前查询的WHERE条件、ORDER BY字段、返回字段，三者是否能被同一个复合索引完全覆盖——少一个字段，就多一次回表；索引顺序错一位，就退回全扫。这不是调参，是索引设计与查询逻辑的咬合。
