MySQL LIMIT分页需写为LIMIT偏移量,数量，第3页每页10条应为LIMIT 20,10；偏移量从0起算，须用(page-1)*size计算，避免页码直当偏移量导致错页，并务必校验参数为非负整数且防SQL注入。
MySQL LIMIT 语句怎么写才不会偏移错乱
分页出错，八成是 LIMIT 的两个参数理解反了。它不是 LIMIT 当前页, 每页条数，而是 LIMIT 偏移量, 数量。比如第 3 页、每页 10 条，偏移量是 (3 - 1) * 10 = 20，得写成 LIMIT 20, 10。
常见错误：直接用页码当偏移量，LIMIT 3, 10 结果查出的是第 4 页数据（跳过了前 3 行）；或者没校验页码是否越界，传入负数或非数字导致 SQL 报错。
- 偏移量必须是非负整数，建议用
max(0, ($page - 1) * $pageSize)计算 - 若用户请求第 1000 页且每页 20 条，偏移量高达 19980，MySQL 扫描成本陡增，这时应考虑游标分页（后文提到）
-
LIMIT后不能跟变量表达式（如LIMIT $offset, $size），必须预处理绑定或拼接前强转为 int
如何安全地把 $_GET['page'] 转成有效页码
直接用 $_GET['page'] 是危险的：空值、字符串、超大数、负数都会让分页逻辑崩掉，轻则查空，重则报错或被 SQL 注入（如果拼 SQL 时没过滤）。
正确做法是强制类型转换 + 边界控制，不依赖 filter_input() 这类可能返回 null 的函数，而用更确定的组合：
立即学习“PHP免费学习笔记（深入）”；
- 用
(int) $_GET['page']强转，自动截断小数和非法字符（"1abc"→1） - 再用
max(1, $page)确保最小为 1，避免 0 或负数导致LIMIT -10, 10这类语法错误 - 可选：加最大页码限制，比如
min($page, 5000)，防暴力遍历全表
示例：$page = max(1, (int)($_GET['page'] ?? 1));
为什么 COUNT(*) 全量统计在大数据量下很慢
传统分页要显示“共 N 条”，就得先 SELECT COUNT(*) FROM table WHERE ...。但这个查询无法利用 LIMIT，必须扫全表或全索引，百万级数据时可能耗时几百毫秒甚至秒级。
这不是 PHP 层能优化的，是 MySQL 的固有限制。尤其带复杂 WHERE 或 JOIN 时，COUNT 会更卡。
- 缓存总数（如 Redis 存
user_count）只适用于读多写少、不要求强一致的场景 - 改用估算值：
SHOW TABLE STATUS LIKE 'users'返回的Rows字段是 InnoDB 的粗略估计，误差可能达 20% - 更推荐游标分页（Cursor-based Pagination）：用上一页最后一条的
id或时间戳做条件，如WHERE id > 12345 ORDER BY id LIMIT 20，完全避开 COUNT
PDO 预处理分页查询怎么防止 SQL 注入
只要不用字符串拼接 SQL，就基本安全。但新手常犯一个错：把 LIMIT 参数也塞进 bindValue() —— 这不行，PDO 不支持对 LIMIT 占位符绑定数值。
正确方式是：WHERE 条件用预处理，LIMIT 参数手动转整型后拼入 SQL 字符串。
- WHERE 部分：用
:status占位符，$stmt->bindValue(':status', $status, PDO::PARAM_STR) - LIMIT 部分：必须提前校验并转 int，再拼进 SQL，例如
" LIMIT $offset, $size" - 绝不能写成
" LIMIT :offset, :size"，PDO 会直接报错或忽略绑定
完整片段示意：
$sql = "SELECT * FROM posts WHERE status = :status ORDER BY id DESC LIMIT $offset, $size";<br>$stmt = $pdo->prepare($sql);<br>$stmt->bindValue(':status', $status, PDO::PARAM_STR);
游标分页的边界判断比 OFFSET 分页更难写对，比如“上一页”需要倒序取、ORDER BY 字段有重复值时怎么去重，这些细节一旦漏掉，就会跳记录或重复展示——实际线上问题大多出在这里，而不是基础语法。
