limit必须置于select语句末尾，仅支持两种形式：limit row_count或limit offset,row_count；须配合order by使用，防注入需参数化或强转整型。
MySQL LIMIT 语法怎么写才不翻车
直接说结论：LIMIT 必须放在查询语句末尾，且不能单独用——它依赖 SELECT，不是独立命令。常见错误是把它当函数调用，比如 LIMIT(10) 或写在 WHERE 前面，结果直接报错 ERROR 1064。
正确姿势只有两种形式：
-
LIMIT row_count：取前 N 行，比如SELECT * FROM users LIMIT 5 -
LIMIT offset, row_count：跳过 M 行后取 N 行，比如SELECT * FROM users LIMIT 20, 10（第 21–30 行）
注意：offset 从 0 开始计数，不是页码。第 3 页（每页 10 条）对应 LIMIT 20, 10，不是 LIMIT 30, 10。
分页查询时 OFFSET 越大越慢，怎么办
当 OFFSET 达到几十万甚至百万级，MySQL 仍会扫描前面所有行（哪怕不返回），导致查询明显变慢。这不是 LIMIT 的 bug，而是它的执行逻辑决定的。
真实场景中，用户翻到第 5000 页（LIMIT 49990, 10）时，性能可能崩掉。解决思路不是“优化 LIMIT”，而是换策略：
- 用主键/时间戳做游标分页：比如上一页最后一条记录
id = 12345，下一页就查SELECT * FROM users WHERE id > 12345 ORDER BY id LIMIT 10 - 避免深度分页：前端限制最大页码，或改用“加载更多”滚动加载
- 加复合索引：如果按
created_at分页，确保有(created_at, id)索引
游标分页不能跳页，但对性能友好；传统 LIMIT offset, size 支持跳页，代价是慢。
ORDER BY 忘加会出什么问题
LIMIT 不保证返回顺序——没加 ORDER BY 时，MySQL 可能每次返回不同行，尤其表有并发写入或使用 InnoDB 的 MVCC 机制时。
典型现象：刷新页面，同一页数据顺序乱了，甚至重复/丢失某条记录。这不是缓存问题，是未定义行为。
必须搭配 ORDER BY 使用，且排序字段最好有索引：
- 安全写法：
SELECT * FROM logs ORDER BY id DESC LIMIT 10 - 危险写法：
SELECT * FROM logs LIMIT 10（结果不可预测） - 如果按无索引字段排序（如
ORDER BY name），LIMIT 前要先走 filesort，更慢
PHP/Python 里拼 LIMIT 参数要防注入
很多人把用户传的页码直接塞进 SQL："LIMIT " . $_GET['page'] * 10 . ", 10"。这等于敞开大门让 SQL 注入进来。
正确做法永远只允许整数，并强转类型：
- PHP：
$offset = (int)($_GET['page'] ?? 1) * 10;，再用mysqli_real_escape_string不够，必须类型断言 - Python（PyMySQL）：
cursor.execute("SELECT * FROM t LIMIT %s, %s", (offset, size))，用参数化防止拼接 - 绝对不要：
"LIMIT " . $_GET['limit']，哪怕你校验了数字，也可能绕过
另外注意：MySQL 默认不限制单次查询返回行数，但有些托管环境（如 phpMyAdmin、阿里云 RDS 控制台）会额外加 LIMIT 1000，实际执行和本地不一致，调试时得看实际执行计划。
