MySQL的LIMIT子句仅支持整数字面量或用户变量，不支持函数调用或表达式，因解析器层面硬限制；须先用SET预计算偏移量再引用变量。
LIMIT 本身不支持函数动态计算偏移量，直接写 LIMIT offset_func(), 10 会报错
为什么 LIMIT 后不能跟函数调用
MySQL 的 LIMIT 子句在语法层面只接受整数字面量或用户变量（@var），不接受表达式或函数调用。这是解析器阶段的硬限制，不是权限或版本问题。
- 错误示例：
SELECT * FROM users LIMIT CEIL(@page * 10), 10→ 报错ERROR 1064 - 正确前提：必须先算出具体数值，再代入
LIMIT - 注意：即使
@page是整数，@page * 10这种乘法表达式也不被允许，除非提前赋值给另一个变量
安全又通用的分页写法：用用户变量预计算
核心思路是把计算逻辑挪到 SET 或子查询里，确保 LIMIT 后只有确定的整数或变量名。
- 推荐方式（存储过程外）：
SET @offset = (@page - 1) * @size; SELECT * FROM users LIMIT @offset, @size; - 单语句兼容方案（适合应用层拼接）：
SELECT * FROM users LIMIT ?, ?，由程序计算好两个整数再绑定参数 - 禁止在 SQL 里用
IF、CEIL等函数包裹偏移量——哪怕看起来“能运行”，也可能在某些版本或执行计划下失效
OFFSET 越大越慢？这不是 LIMIT 的锅，是扫描机制决定的
LIMIT 10000, 20 慢，是因为 MySQL 必须先定位到第 10001 行，中间 10000 行仍要读取（哪怕不返回）。优化关键不在 LIMIT 写法，而在避免深分页。
- 用游标分页替代：记录上一页最后的
id，下一页查WHERE id > ? ORDER BY id LIMIT 20 - 加复合索引：比如分页按
created_at DESC，就建INDEX (status, created_at)（把过滤字段放前面） - 不要依赖
SQL_CALC_FOUND_ROWS：已废弃，且严重拖慢 COUNT；需要总数时单独走SELECT COUNT(*)并缓存
真正容易被忽略的是：当业务要求“跳转到任意页”且数据量极大时，没有银弹。要么接受延迟，要么改交互（比如只允许前后翻页+搜索），要么用 ES 等专用分页引擎。MySQL 的 LIMIT 就是个朴素的截断工具，别指望它扛住百万级 offset。
