limit offset, size在存储过程中变慢是因为mysql必须扫描并跳过前offset行，如limit 999990,10需定位到第1000000行，导致全表扫描压力陡增；应改用where id > last_id order by id limit 10，并确保排序字段有索引。
为什么直接用 LIMIT offset, size 在存储过程中会变慢
因为 MySQL 必须先扫描并跳过前 offset 行，哪怕你只想要 10 条数据。当 offset 达到几十万甚至百万级时，SELECT ... LIMIT 999990, 10 实际要定位到第 1000000 行再取数，全表扫描压力陡增。执行计划里 rows 字段常显示远超预期的扫描行数，且 key 为 NULL，说明根本没走索引。
用主键/有序字段 + 条件过滤替代 LIMIT offset
前提是表有单调递增、基本连续的主键（如 id）或业务时间字段（如 create_time），且查询按该字段排序。核心思路是：不跳行，而是“从上一页末尾值继续往后查”。
- 若上一页最后一条记录
id = 1024，下一页就写WHERE id > 1024 ORDER BY id LIMIT 10 - 必须确保
ORDER BY字段有索引（例如KEY idx_id (id)），否则仍会全表扫描 - 不能依赖
OFFSET动态计算，需前端/调用方传入上一页的锚点值（如@last_id） - 注意：主键删除后不连续时，结果可能跳过某些行（但多数业务可接受，且性能收益远大于这点偏差）
在存储过程中安全拼接带条件的分页 SQL
MySQL 存储过程不支持直接参数化 ORDER BY 或表名字段名，必须用预处理语句动态拼接，但要严防 SQL 注入和语法错误。
- 表名、字段名必须白名单校验，不可直接拼接用户输入；建议用
CASE映射合法表名：CASE WHEN tableName = 'user' THEN 'user' ELSE NULL END - 拼接前检查
@last_id是否为正整数：IF @last_id - 完整拼接示例：
SET @sql = CONCAT('SELECT * FROM ', tableName, ' WHERE id > ? ORDER BY id LIMIT ', pageSize);，然后用EXECUTE stmt USING @last_id; - 务必
DEALLOCATE PREPARE stmt，否则连接内反复创建会耗尽资源
大数据量下避免 COUNT(*) 全表统计总页数
对千万级表执行 SELECT COUNT(*) FROM t 本身就很慢，而分页接口往往并不真需要精确总页数（比如搜索结果展示“约 120 万条匹配”即可）。
- 改用近似值：
SHOW TABLE STATUS LIKE 't'查Rows字段（InnoDB 估算值，误差通常在 10% 内） - 或加缓存：首次查总数后写入 Redis，TTL 设为 1 小时，后续分页请求复用缓存值
- 更激进做法：前端只提供“下一页”按钮，不显示总页码 —— 用户滚动到底部才触发下一页，彻底规避总数计算
- 如果业务强依赖精确总数，考虑异步更新汇总表：
INSERT INTO table_count (tbl, cnt) VALUES ('t', (SELECT COUNT(*) FROM t)) ON DUPLICATE KEY UPDATE cnt = VALUES(cnt)
实际中最容易被忽略的一点：分页优化不是单改 SQL 就完事，而是整个链路要配合——前端必须保存并传递锚点值，后端存储过程要拒绝非法 offset 请求，DBA 要确认排序字段索引真实生效。漏掉任一环，性能还是卡在原地。
