mysql如何利用索引实现快速分页_mysql分页查询加速

LIMIT offset, size 越往后越慢是因为MySQL必须扫描前offset行才能定位数据，I/O与CPU成本线性上升；应优先用游标分页（基于有序字段如id过滤）和覆盖索引优化，仅在需跳页时限制offset范围或降级处理。为什么 LIMIT offset, size 越往后越慢因为 MySQL 在执行 LIMIT 100000, 20 这类语句时，必须先扫描前 100000 行（哪怕不返回），再取后面 20 行。索引能跳过全表扫描，但无法跳过“跳过 N 行”这个动作——offset 越大，引擎越要按索引顺序逐条计数，I/O 和 CPU 成本线性上升。常见错误现象：EXPLAIN 显示 rows 高达几十万，Extra 列出现 Using filesort 或空值（说明没用上覆盖索引）。使用场景：后台列表页、数据导出、后台分页接口，尤其当总记录数超百万时根本原因不是“没建索引”，而是“索引没被用来跳过 offset”如果排序字段无索引，或 ORDER BY 和 WHERE 字段组合不匹配索引最左前缀，索引直接失效用游标分页替代 LIMIT offset, size核心思路：不依赖行号，改用上一页最后一条的主键（或唯一、有序字段）作为下一页起点。MySQL 可以用索引直接定位，跳过所有前面的行。假设按 id 升序分页，第一页查 SELECT * FROM t ORDER BY id LIMIT 20，拿到第 20 条的 id = 12345，第二页就写成：SELECT * FROM t WHERE id > 12345 ORDER BY id LIMIT 20这样 MySQL 直接在索引中二分查找 id > 12345 的第一条，然后往后取 20 行，完全避开 offset 扫描。必须有可用于排序和过滤的单调字段（推荐主键 id，或带索引的 created_at）WHERE 条件必须和 ORDER BY 字段一致，否则可能漏数据或重复不能跳页（比如从第 1 页直接到第 100 页），只适合“下一页/上一页”场景如果排序字段有重复值（如多个记录 created_at 相同），需加二级排序字段（如 ORDER BY created_at, id）并同步用于 WHERE联合索引设计要点：WHERE + ORDER BY + SELECT 三者对齐分页快不快，最终取决于能不能走**覆盖索引 + 索引有序扫描**。单列索引往往不够，得靠联合索引把查询路径“焊死”。 Tellers AI Tellers是一款自动视频编辑工具，可以将文本、文章或故事转换为视频。