MySQL 5.7分页需用@offset用户变量计算偏移量，因不支持窗口函数和参数化LIMIT；行号需在FROM中用(SELECT @row_number:=0)初始化；大偏移量性能差，应改用游标分页。
MySQL 5.7存储过程中必须用@offset变量计算偏移量
MySQL 5.7不支持窗口函数，也没有LIMIT ? OFFSET ?的参数化写法，所以不能直接把页码和每页大小当参数传进LIMIT。你必须在存储过程里用用户变量动态算出偏移值，再代入LIMIT。否则会报错：ERROR 1064 (42000): You have an error in your SQL syntax——因为LIMIT后面只接受常量或变量，但变量必须是会话级用户变量（@xxx），不能是存储过程参数（IN page INT）。
正确做法是：
- 先用
SET @offset = (page - 1) * page_size;算出偏移量 - 再用
LIMIT @offset, page_size——注意这里page_size可以是参数，但@offset必须是用户变量 - 务必加
ORDER BY，否则分页结果不稳定（尤其有重复排序字段时）
调用前必须显式初始化@row_number才能加序号
如果分页同时要带行号（比如导出报表），在5.7里只能靠@row_number := @row_number + 1。但这个变量不会自动重置，上一次查询留下的值会影响下一次结果。常见错误是：第一次调用返回行号1~10，第二次调用却从11开始。
解决方案是把初始化写死在查询里，且必须放在FROM子句中：
SELECT @row_number := @row_number + 1 AS row_num, t.*
FROM (SELECT * FROM users ORDER BY id DESC LIMIT @offset, 10) AS t,
(SELECT @row_number := 0) AS init;
关键点：
-
(SELECT @row_number := 0)必须作为派生表出现在FROM里，放WHERE或SET语句后都不可靠 - 不能在存储过程开头用
SET @row_number = 0就完事——它可能被优化器提前执行或跳过 - 如果查询含
JOIN，变量递增顺序可能错乱，建议只在单表+简单过滤场景用
大偏移量下LIMIT offset, size会严重拖慢性能
当查第1000页（offset = 9990）时，MySQL仍要扫描并丢弃前9990行，哪怕只取10条。explain显示type: index，说明它在遍历主键索引树，I/O和CPU开销陡增。
替代方案不是改存储过程逻辑，而是改调用方式：
- 前端禁用“跳转到指定页”，只提供“下一页/上一页”，用上一页最后一条的
id做条件：WHERE id - 如果必须支持任意页码，改用子查询定位边界：
WHERE id - 避免在存储过程中封装这种低效逻辑——把分页策略交给应用层判断更可控
存储过程里不能直接返回总记录数，得靠SQL_CALC_FOUND_ROWS
分页通常需要知道总页数，但SELECT COUNT(*)会额外扫一遍表。MySQL 5.7支持SQL_CALC_FOUND_ROWS配合FOUND_ROWS()，但要注意它只对紧接其后的SELECT FOUND_ROWS()有效，且在存储过程中需用SELECT语句显式返回：
SELECT SQL_CALC_FOUND_ROWS * FROM users WHERE status = 1 ORDER BY id DESC LIMIT @offset, 10; SELECT FOUND_ROWS() AS total_count;
陷阱：
-
FOUND_ROWS()返回的是上一条SELECT的**未加LIMIT的总行数**，不是当前结果集大小 - 如果中间穿插了其他
SELECT（比如日志记录），FOUND_ROWS()会被覆盖 - 高并发下
FOUND_ROWS()可能不准，建议业务层缓存总数量或用近似值
真正难处理的不是语法，而是当OFFSET超过十万级后，任何基于LIMIT的存储过程都会变成性能黑洞——这时候该想的不是怎么写得更漂亮，而是要不要换架构。
