“MySQL 无法‘跳过’中间行必须物理扫描所有前置行”是深度分页LIMIT offset, size性能灾难的根本原因。这并非 MySQL 的设计缺陷而是由其存储引擎架构与 SQL 语义决定的必然结果。一、B 树结构为什么不能“跳过”▶ 1.InnoDB 聚簇索引布局数据存储行数据按主键顺序存储在B 树叶子节点叶子节点通过双向链表连接示例[1] ↔ [2] ↔ [3] ↔ ... ↔ [1000000] ↔ [1000001] ↔ ...▶ 2.LIMIT 1000000, 10的执行路径定位 id1遍历链表到 id1000000继续读取 10 行返回结果关键限制B 树不存储“第 N 行的物理位置”必须从头或上一次位置顺序遍历链表核心认知B 树优化的是“范围查询”而非“随机跳转”二、执行模型SQL 语义的约束▶ 1.SQL 标准的要求ORDER BYLIMIT语义必须返回排序后第 (offset1) 到 (offsetsize) 行无法假设数据分布如自增 ID 连续▶ 2.执行器的工作方式步骤打开表扫描Table Scan或索引扫描Index Scan逐行读取并计数当计数 offset 时开始收集结果伪代码intcount0;while(rowfetch_next_row()){if(countoffset){result.add(row);if(result.size()size)break;}count;}关键点执行器必须保证结果的正确性无法“猜测”跳过行三、替代方案如何实现真正的“跳过”▶ 方案 1游标分页推荐原理利用已知的排序字段值直接定位起始点示例-- 上一页最后 id1000000SELECT*FROMordersWHEREid1000000ORDERBYidLIMIT10;执行计划type: range→ 直接跳转到 B 树的id1000000位置仅扫描 10 行▶ 方案 2延迟关联Deferred Join原理先通过覆盖索引获取主键再回表示例SELECTt.*FROMorders tINNERJOIN(SELECTidFROMordersORDERBYidLIMIT1000000,10)tmpONt.idtmp.id;适用场景主键为聚簇索引InnoDB覆盖索引可避免回表▶ 方案 3记录偏移量静态数据原理预先计算每页的起始主键存储到缓存示例// Redis 存储第 100000 页起始 ID$startIdRedis::get(page_100000_start_id);$rowsDB::select(SELECT * FROM orders WHERE id ? ORDER BY id LIMIT 10,[$startId]);四、避坑指南陷阱破局方案忽略排序字段唯一性复合排序末尾加主键确保连续未使用覆盖索引确保WHEREORDER BY字段有联合索引盲目使用 OFFSET深度分页必用游标方案五、终极心法**“跳过不是功能而是索引的舞蹈——当你利用游标你在跳过扫描当你延迟关联你在减少回表当你预计算偏移你在铸造缓存。真正的查询优化始于对存储的敬畏成于对细节的精控。”结语从今天起深度分页必用游标方案WHERE id last_id用EXPLAIN验证执行计划typerange监控慢查询日志long_query_time1因为最好的分页不是跳过百万行而是精准定位下一程。