LIMIT 必须放在整个 SELECT 语句的最后，严格位于 ORDER BY 和 GROUP BY 之后、WHERE 之后；写在 WHERE 或 ORDER BY 中间会报错。
MySQL 的 LIMIT 用在 WHERE 之后还是 ORDER BY 之后？
LIMIT 必须放在整个 SELECT 语句的最后，且严格位于 ORDER BY 和 GROUP BY 之后（如果有）。写在 WHERE 中间或 ORDER BY 前会直接报错：ERROR 1064 (42000)。
常见错误写法：SELECT * FROM users WHERE id > 10 LIMIT 5 ORDER BY created_at DESC —— 这里 LIMIT 插在中间，语法非法。
正确顺序是：SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT ...
- 如果没用
ORDER BY，LIMIT仍有效，但结果顺序不确定（依赖存储引擎和索引扫描顺序） - 分页场景下不加
ORDER BY可能导致同一页数据反复出现或跳过 -
LIMIT在执行计划中属于“limit handler”，发生在排序/聚合之后，所以它截的是最终结果集
LIMIT 两个参数：offset 和 row_count 怎么理解？
LIMIT offset, row_count 是标准写法，第一个数是跳过的行数（从 0 开始），第二个是返回行数。比如 LIMIT 20, 10 表示跳过前 20 行，取接下来的 10 行——这是第 3 页、每页 10 条的典型写法。
注意：LIMIT 10 OFFSET 20 是等价的 ANSI SQL 写法，在 MySQL 中也支持，但部分旧版本（如 5.5 之前）只认逗号分隔形式。
- 当
offset很大（如几百万），MySQL 仍需扫描并丢弃前面所有行，性能急剧下降 -
row_count为 0 时返回空结果集，不报错，可用于“只检查是否存在”（配合COUNT(*)更合适） - 如果
row_count超出剩余行数，MySQL 自动截断，不会报错
用 LIMIT 实现“取最新 5 条记录”为什么必须加 ORDER BY？
因为 InnoDB 表没有隐式物理顺序，SELECT * FROM logs LIMIT 5 返回的未必是最近插入的 5 条。实际返回取决于聚簇索引扫描方向、是否有缓存、是否走覆盖索引等，完全不可靠。
正确做法是明确按时间字段排序：SELECT * FROM logs ORDER BY created_at DESC LIMIT 5。
- 确保
created_at上有索引，否则ORDER BY+LIMIT会触发 filesort，效率低 - 如果
created_at有重复值，建议追加主键（如id）做二级排序：ORDER BY created_at DESC, id DESC，避免分页结果不稳定 - 不要依赖
INSERT ... SELECT ... LIMIT来“复制最新 N 条”，除非已加锁或事务隔离级别足够高
大偏移量分页（如 LIMIT 1000000, 20）怎么优化？
直接用大 OFFSET 会导致 MySQL 扫描一百万零二十行再丢弃前一百万，I/O 和 CPU 开销巨大。这不是 LIMIT 本身的问题，而是查询设计问题。
更可行的替代方案是“游标分页（cursor-based pagination）”：用上一页最后一条记录的排序字段值作为下一页起点。
- 例如上一页最后一条是
created_at = '2024-05-01 10:23:45', id = 88721，下一页查：SELECT * FROM posts WHERE created_at - 该方式避免了 OFFSET，每次只查所需范围，响应稳定
- 前提是排序字段组合具有唯一性或能构造唯一条件；否则可能漏数据或重复
真正需要 LIMIT 大偏移的场景极少，多数时候是业务逻辑没对齐数据模型——比如后台导出全量数据，应该用流式游标或分批主键范围查询，而不是靠 LIMIT 跳着扫。
