LIMIT offset, size 在大偏移量时变慢，是因为MySQL需逐行扫描并丢弃前offset行，导致索引查找、IO和内存拷贝大量浪费；应改用WHERE+排序字段值（如updated_at）的游标分页替代OFFSET。
为什么 LIMIT offset, size 在大偏移量时会变慢
MySQL 执行 LIMIT 1000000, 20 时，并不是直接跳到第 1000001 行，而是从排序后结果集开头逐行扫描，直到累计读满 1000020 行，再丢掉前 1000000 行——这中间所有被丢弃的行，索引查找、IO、内存拷贝全做了，纯属浪费。
常见错误现象包括：
- 第 1 页查得飞快，第 1000 页开始明显卡顿，第 10000 页超时或锁表
-
EXPLAIN显示rows值远大于你期望返回的条数（比如显示扫描 200 万行，只取 20 条） - 即使
ORDER BY字段有索引，offset越大，性能衰减越接近线性
用 WHERE + 排序字段值替代 OFFSET 的实操写法
核心思路：把“我要第 N 页”转成“我要 updated_at 小于上一页最后一条的 updated_at 的最新 20 条”。前提是排序字段单调、稳定、有索引。
实操建议：
- 必须给排序字段（如
updated_at或id）建单独索引或作为联合索引最左前缀 - 首次查询仍需带
LIMIT和ORDER BY，但不带OFFSET：SELECT * FROM orders ORDER BY updated_at DESC LIMIT 20 - 后续每页传入上一页最后一条的
updated_at值（注意时区与精度，建议用datetime(3)或BIGINT时间戳） - 查询语句写成：
SELECT * FROM orders WHERE updated_at - 如果存在并发更新导致同时间戳多条记录，需追加二级排序字段（如
id）防漏/重：WHERE (updated_at, id)
存储过程中如何安全封装带状态的分页逻辑
不能在存储过程里直接拼接 OFFSET 参数做深度分页——那只是把应用层的性能问题藏进了数据库，没解决根本问题。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
推荐做法是让存储过程接收“游标值”（cursor），而非页码：
- 输入参数定义为：
IN p_cursor_updated_at DATETIME(3), IN p_cursor_id BIGINT, IN p_size INT - 主查询用游标条件代替
OFFSET：WHERE (updated_at, id) - 返回结果集的同时，显式
SELECT出本页最后一条的(updated_at, id)作为下一页游标（避免应用层再查一遍） - 首次调用时，
p_cursor_updated_at可设为NULL，用IFNULL判断并走无条件首查分支 - 务必在存储过程开头加
SQL_CALC_FOUND_ROWS？别加——它会让优化失效；总条数另用SELECT COUNT(*)异步查，或前端按需不查
容易被忽略的边界与兼容性坑
真实业务中，以下几点常被跳过，却直接导致数据错乱或性能回退：
- 排序字段允许
NULL？MySQL 中NULL在DESC排序时排最前，会导致游标比较失效；要么WHERE updated_at IS NOT NULL过滤，要么建索引时指定NOT NULL - 用
id当游标更简单，但前提是id严格递增且不删不复用；若业务含软删除或归档，id不再代表逻辑顺序，必须换时间字段 - MySQL 5.7 默认可重复读隔离级别下，同一事务内多次执行游标分页，可能因 MVCC 快照滞后看到“跳变”数据；建议单页查询独立事务，或加
SELECT ... FOR UPDATE（慎用） - 如果你用的是 MySQL 8.0+，可考虑
WINDOW函数配合ROW_NUMBER()做逻辑分页，但仅适合中小结果集（全表排序开销大），不可用于百万级深分页场景
游标分页不是银弹——它牺牲了“跳转任意页”的灵活性，换来稳定性能。一旦决定用，就要在 API 设计、前端交互、缓存策略上整体对齐，否则游标值传丢了，就真翻不到下一页了。
