因为mysql需先扫描1000020条记录取id再回表20次，引发大量随机i/o；延迟关联通过子查询仅取id再join，将回表压缩至20次，但要求子查询走覆盖索引且rows控制在千级以内。
为什么 LIMIT 1000000, 20 会卡住数据库？
不是因为扫描慢，而是因为 MySQL 必须先查出 1,000,020 条记录的主键，再拿着这 100 万+ 个 ID 去聚集索引里逐条回表——哪怕你最终只用最后 20 行。这导致大量随机 I/O、Buffer Pool 被污染、查询线程长时间阻塞。
典型现象：SHOW PROCESSLIST 里看到状态长期卡在 Sending data 或 Copying to tmp table；慢日志里 Rows_examined 高达百万级，但 Rows_sent 只有 20。
延迟关联（Deferred Join）怎么写才有效？
核心是：用子查询先只走索引拿到 ID，再用主键 IN 关联原表——把回表动作压缩到仅 20 次。
- 必须确保子查询里的
ORDER BY字段有索引（比如create_time），且该索引能覆盖排序 + 过滤条件 - 子查询不能带
SELECT *，只选主键（如id），否则无法触发覆盖索引优化 - 外层 JOIN 或 IN 的数据量必须严格控制在每页条数（如 20），不能让子查询返回过多 ID
示例（按时间倒序分页）：
SELECT t.* FROM orders AS t INNER JOIN ( SELECT id FROM orders WHERE create_time <p>注意：<code>OFFSET</code> 在子查询里仍存在，但只作用于轻量级的 ID 查询，不触发回表。</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2334" title="MySQL"><img src="https://img.php.cn/upload/skill/000/000/081/178900927846657.jpg" alt="MySQL" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="overflowclass">MySQL</a> <p class="overflowclass">编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。</p> </div> <a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div><h3> <code>WHERE id > ? ORDER BY id ASC LIMIT ?</code> 为什么有时漏数据？</h3><p>这不是语法错，而是业务逻辑陷阱：当多行 <code>id</code> 对应相同排序字段值（比如同一秒插入多笔订单），<code>WHERE id > 1000</code> 会跳过所有 <code>id=1001</code> 但 <code>create_time</code> 等于上一页末尾时间的记录。</p>
- 漏数据只发生在排序字段非唯一、且存在重复值时
- 用
id本身排序（ORDER BY id ASC）可彻底规避，但业务上往往需要按时间/状态排序 - 若必须按非唯一字段排序，应在
ORDER BY后追加主键作为第二排序项，例如ORDER BY create_time DESC, id DESC
游标方案更稳，但要求前端记住上一页最后一条的 create_time 和 id 两个值。
延迟关联在哪些场景下会失效？
它不是银弹。以下情况会退回原始性能：
- 子查询中用了
OR、函数（如DATE(create_time)）、隐式类型转换，导致索引失效 - 过滤条件（
WHERE）太宽泛，子查询扫描行数仍达数十万，JOIN成本反超 - MySQL 版本低于 5.6，子查询未被物化（Materialize），优化器可能选择嵌套循环而非哈希连接
- 表使用 MyISAM 引擎——不支持延迟关联所需的索引合并与物化子查询
真正关键的不是“用了没”，而是 EXPLAIN 里看子查询是否走了 type=range 或 index，且 rows 是否落在千级以内。
