必须配合ORDER BY使用LIMIT，否则结果无序且不可靠；优先用游标分页替代OFFSET；注意不同数据库分页语法差异；子查询和CTE中LIMIT需谨慎使用。

MySQL里用LIMIT直接截断结果，但别漏写ORDER BY

不加ORDER BY的LIMIT是危险的：数据库可能每次返回不同行，尤其表有并发写入时。MySQL不保证无序查询的行顺序，LIMIT 10可能今天取前10条，明天就变成另10条。

• 必须配合确定性排序，比如ORDER BY id ASC或ORDER BY created_at DESC
• LIMIT放在语句末尾，语法简单：SELECT * FROM users ORDER BY id LIMIT 20
• 如果只想要第1条，写LIMIT 1比LIMIT 0,1更清晰，也少一个参数要维护

分页查第N页数据，OFFSET越往后越慢

OFFSET本质是跳过前N行再取数据，数据库仍需扫描并丢弃那些行。查第1000页（每页20条）相当于跳过20000行——索引可能失效，I/O和CPU开销陡增。

• 替代方案优先考虑「游标分页」：用上一页最后一条记录的id做条件，如WHERE id > 12345 ORDER BY id LIMIT 20
• 真要用OFFSET，确保ORDER BY字段有索引，且避免OFFSET超过几万
• PostgreSQL和SQLite支持LIMIT/OFFSET，但SQL Server得用OFFSET ... FETCH NEXT，语法不同

不同数据库的分页语法差异不止是关键字

不是所有数据库都认LIMIT，硬套会报错。比如SQL Server报Incorrect syntax near 'LIMIT'，Oracle旧版本压根没LIMIT。

• MySQL / PostgreSQL / SQLite：LIMIT 20 OFFSET 40 或 LIMIT 40, 20（MySQL特有逗号写法）
• SQL Server 2012+：ORDER BY id OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY
• Oracle 12c+：OFFSET 40 ROWS FETCH NEXT 20 ROWS ONLY；老版本得用ROWNUM嵌套子查询，容易出错
• 如果用ORM（如Django ORM、SQLAlchemy），让框架生成适配方言的分页语句，别手写原生SQL

LIMIT在子查询或CTE里被忽略？注意执行顺序

有些场景下LIMIT看似写了却没生效，常见于子查询未加ORDER BY，或者CTE里用了LIMIT但外层查询又没约束。

• 子查询中LIMIT必须搭配ORDER BY才有意义，否则优化器可能直接忽略
• CTE（WITH语句）里的LIMIT只作用于该CTE，不会影响主查询结果集大小
• 聚合后分页要小心：先GROUP BY再LIMIT，别在聚合前LIMIT——那样会漏掉本该合并的分组
• 测试时用EXPLAIN看执行计划，确认LIMIT是否真正下推到扫描层

分页这事，表面是加个LIMIT，实际牵扯排序稳定性、索引利用、方言兼容和执行计划。最容易被忽略的是：没有ORDER BY的LIMIT根本不算分页，只是随机抽样。