深分页慢的本质是MySQL需扫描并丢弃前offset行，游标分页（Keyset Pagination）通过WHERE+唯一排序字段替代LIMIT offset,size实现恒定性能，但不支持任意页跳转。
深分页慢不是因为数据多，而是MySQL必须扫描并丢弃前 offset 行——哪怕你只要20条，它也得把前100万行全捞出来再扔掉。真正有效的解法不是调优索引或加缓存，而是绕开 LIMIT offset, size 这个执行模型本身。
用游标分页（Keyset Pagination）替代OFFSET
这是目前最稳定、性能恒定的方案，前提是排序字段有唯一性且能建立索引（如主键 id 或带唯一约束的 create_time + id 组合）。
- 上一页最后一条记录是
id = 100456，下一页就写：SELECT * FROM orders WHERE id > 100456 ORDER BY id ASC LIMIT 20 - 如果排序含时间字段且可能重复，必须补唯一列去重，例如：
WHERE (create_time, id) > ('2026-09-28 10:22:11', 100456) - 不能跳转任意页码（比如直接翻到第800页），只适合“下一页”“上一页”或无限滚动场景
- 注意：倒序分页要改不等号方向，
ORDER BY create_time DESC对应WHERE create_time
延迟关联（Deferred Join）减少回表次数
当必须支持跳页（如用户手动输入页码）、又无法改业务逻辑时，用覆盖索引先捞ID，再关联查全量字段，能大幅降低I/O压力。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 原始慢查询：
SELECT * FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 100000, 20 - 优化后：
SELECT o.* FROM orders o INNER JOIN (SELECT id FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 100000, 20) t ON o.id = t.id - 关键点：子查询只查
id，走的是二级索引（如idx_status_create_time），避免回表；外层JOIN才回表取完整行 - 性能提升明显，但
offset超过百万后仍会变慢——毕竟子查询还是得扫100万+行
避免常见误操作和隐性陷阱
很多“优化”实际无效，甚至让问题更隐蔽。
- 给
ORDER BY字段加索引 ≠ 解决深分页——索引只是避免排序，不减少扫描行数 -
SELECT *在深分页中永远是坏主意；即使加了覆盖索引，一旦字段增多或加了TEXT/BLOB，索引就失效 - 用
IN替代子查询 JOIN？MySQL在IN子句里不支持LIMIT，语法直接报错：ERROR 1235 (42000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' - 误以为
SQL_CALC_FOUND_ROWS可以加速总数统计——它会让MySQL强制扫描全表，比单独跑COUNT(*)更慢
真正难处理的不是技术方案选型，而是业务是否允许放弃“跳转指定页码”这个功能。一旦接受游标分页，性能问题就消失了；但如果产品硬要求支持页码输入，那延迟关联就是兜底选择——它不会让你的接口从3秒降到3毫秒，但能从3秒压到300毫秒，而且可控。
