mysql中limit语法必须为limit offset, row_count，offset在前、row_count在后，顺序不可颠倒；写反会报error 1064语法错误，且大offset性能差，应配合order by及游标分页优化。
MySQL LIMIT语法里offset和row_count哪个在前
顺序不能错：LIMIT offset, row_count，不是LIMIT row_count, offset。MySQL官方语法明确要求偏移量（跳过多少行）必须写在前面，数量写在后面。写反了会报错ERROR 1064，提示SQL语法错误。
常见错误现象：用PostgreSQL或SQL Server习惯写LIMIT 10 OFFSET 20，但在MySQL 5.7及更早版本不支持这种写法（MySQL 8.0+才支持OFFSET关键字）。所以老项目里硬套标准SQL写法会直接失败。
- 第1页（每页10条）：用
LIMIT 0, 10 - 第2页：用
LIMIT 10, 10（跳过前10条，取10条） - 第n页：计算为
LIMIT (n-1)*10, 10，注意(n-1)*10必须是整数且非负
大偏移量下LIMIT性能急剧下降怎么办
LIMIT 1000000, 20这类查询慢，不是因为取20条，而是MySQL必须先扫描并跳过前100万行——哪怕加了索引，也得逐行计数到第100万条才开始返回结果。
真实业务中，用户翻到第5万页时，offset可能已上百万，这时响应时间常超秒级。优化核心思路是避免依赖offset计数。
- 用游标分页：记录上一页最后一条的
id（或时间戳），下一页查WHERE id > last_id ORDER BY id LIMIT 20 - 确保
ORDER BY字段有索引，且和WHERE条件能走同一索引 - 禁止用户无限制翻页，前端限制最大页码，或后端对
offset > 10000的请求直接返回空或提示
为什么ORDER BY必须和LIMIT一起用才安全
没ORDER BY的LIMIT结果是不确定的。InnoDB引擎不保证物理存储顺序，多次执行SELECT * FROM user LIMIT 10可能返回不同10条记录，尤其在有并发写入时。
分页场景下，如果只靠LIMIT不排序，第1页和第2页的数据可能重复或遗漏——这不是bug，是MySQL的行为定义。
- 正确写法：
SELECT * FROM article ORDER BY created_at DESC, id DESC LIMIT 0, 10 - 排序字段必须有索引，否则
ORDER BY本身就会触发filesort，叠加LIMIT更慢 - 多个排序字段时，注意
DESC/ASC一致性，混合方向可能使索引失效
MySQL 8.0+的OFFSET写法能替代传统LIMIT吗
可以写LIMIT 20 OFFSET 1000，语义和LIMIT 1000, 20等价，但底层执行逻辑完全一样——仍需跳过前1000行。语法糖不解决性能问题。
新写法唯一优势是可读性略好，尤其配合FETCH FIRST（如FETCH FIRST 20 ROWS ONLY），但仅限MySQL 8.0+，且迁移旧代码成本低，没必要强切。
- 兼容性风险：若应用要支持MySQL 5.7，就不能用
OFFSET - ORM框架（如MyBatis、Sequelize）生成的SQL通常还是用传统
LIMIT a,b格式 - 真正要改的是分页逻辑，不是SQL写法——游标分页在新旧版本里都有效
实际分页最易被忽略的点：ORDER BY字段存在重复值时，即使加了索引，相同排序值的行物理顺序也不稳定，会导致同一页数据抖动。解决方案是补一个唯一字段（比如id）进排序条件，让结果彻底确定。
