limit必须放在select语句末尾且严格位于order by之后，因为mysql语法要求其作为最终子句截取排序/聚合后的结果集；放错位置（如where或group by中间）会触发error 1064语法错误。
LIMIT 只能用在 SELECT 语句末尾，且必须放在 ORDER BY 之后
为什么 LIMIT 放错位置会报错
MySQL 要求 LIMIT 必须是整个查询的最后一个子句。如果写在 WHERE 或 GROUP BY 后面但还没到结尾，就会触发 ERROR 1064。常见错误写法：SELECT * FROM users WHERE id > 10 LIMIT 5 GROUP BY status —— 这里 LIMIT 出现在 GROUP BY 前，语法非法。
- 正确顺序：SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT
- 如果用了
ORDER BY，LIMIT必须在其后；没ORDER BY也能用，但结果顺序不确定 - 子查询中用
LIMIT需加括号包裹，否则报错：(SELECT id FROM logs ORDER BY ts DESC LIMIT 1)
LIMIT offset, row_count 和 LIMIT row_count 的区别
两种写法语义不同，选错会导致跳过数据或查不到预期行。
-
LIMIT 10等价于LIMIT 0,10：从第 0 行开始取 10 行 -
LIMIT 20,10：跳过前 20 行，取接下来的 10 行（常用于分页） - 注意：offset 从 0 开始计数，不是页码；第 3 页每页 10 条应写
LIMIT 20,10，不是LIMIT 30,10 - 大 offset 性能差：MySQL 仍需扫描前 offset + row_count 行，建议用游标（cursor-based）替代
在 UPDATE 和 DELETE 中不能直接用 LIMIT（除非开启安全模式）
默认情况下，UPDATE 和 DELETE 不允许带 LIMIT，否则报错 ERROR 1175（Safe Update Mode）。这不是语法限制，而是 MySQL 客户端的安全保护机制。
- 临时关闭：执行
SET SQL_SAFE_UPDATES = 0，操作完再设回1 - 更安全的做法是显式加 WHERE 条件，例如
DELETE FROM logs WHERE created_at - 某些版本支持
UPDATE ... ORDER BY ... LIMIT，但行为依赖存储引擎，InnoDB 下有效，MyISAM 可能不一致
使用 LIMIT 时 ORDER BY 不可省略（尤其分页场景）
没 ORDER BY 时，LIMIT 返回的行顺序由存储引擎决定，可能每次查询都不一样。这对分页是灾难性的 —— 同一页可能重复出现或漏掉记录。
- 错误示例：
SELECT id,name FROM products LIMIT 10,10（无排序，结果不可靠） - 正确做法：
SELECT id,name FROM products ORDER BY id ASC LIMIT 10,10 - 复合排序更稳：
ORDER BY status ASC, id DESC，避免因主键重复导致分页偏移 - 如果排序字段有大量重复值，务必加上唯一字段（如主键）做二级排序，否则
LIMIT的边界可能漂移
真正麻烦的是 offset 越大越慢，以及排序字段没索引时 LIMIT 会拖垮整个查询。别只盯着语法对不对，得看执行计划里有没有用上索引。
