pdo分页需校验页码和每页数为整型并白名单控制，limit/offset须手动拼接（因pdo不支持绑定），count(*)须单独查询且条件严格同步，避免rowcount()误用，大偏移量应改用游标分页。
怎么用 PDO 的 prepare() 和 bindValue() 做安全分页
直接拼接 OFFSET 和 LIMIT 是危险的，尤其当页码来自 URL 参数时。PDO 本身不支持对 LIMIT 或 OFFSET 占位符绑定（MySQL 不允许预处理语句中绑定这些值），所以必须手动校验并转为整型。
正确做法是：先用 filter_var($page, FILTER_VALIDATE_INT) 验证页码，再用 max(1, $page) 保证最小为 1；每页条数也需固定或白名单控制（如只允许 10/20/50）。
$page = filter_var($_GET['page'] ?? 1, FILTER_VALIDATE_INT) ?: 1;$perPage = in_array($_GET['limit'] ?? 20, [10, 20, 50]) ? (int)$_GET['limit'] : 20;$offset = ($page - 1) * $perPage;- 查询时写死
LIMIT :limit OFFSET :offset，再用bindValue('limit', $perPage, PDO::PARAM_INT)—— 注意：MySQL 允许对LIMIT绑定整型参数，但部分旧版本 PDO 驱动可能不支持，稳妥起见仍建议用sprintf()拼接LIMIT %d OFFSET %d（前提是变量已严格校验为 int）
为什么 COUNT(*) 查询不能复用同一个预处理语句
分页必须知道总记录数来算页码总数，但 COUNT(*) 和实际数据查询的 SQL 结构不同（比如带 GROUP BY、JOIN、WHERE 条件一致但字段不同），无法共用一个 prepare() 对象。
常见错误是试图用同一语句改写 SELECT * 为 SELECT COUNT(*) 后还用原 execute()，这会失败——因为占位符数量、类型甚至语义都可能变化。
立即学习“PHP免费学习笔记（深入）”；
- 必须单独写一条
SELECT COUNT(*) FROM ... WHERE ...，条件逻辑和主查询严格同步 - 如果主查询有动态
WHERE（如搜索关键词），COUNT 查询里也要一模一样复制，不要漏掉AND或括号层级 - 避免在 COUNT 查询中使用
DISTINCT或复杂子查询，除非业务真需要去重计数；否则性能差且易出错
如何避免 OFFSET 大了以后查询变慢
当 OFFSET 达到几十万，MySQL 仍要扫描前面所有行，即使只取 20 条，响应也会明显延迟。这不是 PDO 的问题，而是 SQL 分页模型的固有缺陷。
替代方案不是换库，而是换思路：用「游标分页（cursor-based pagination）」，即基于上一页最后一条记录的主键或时间戳继续查。
- 例如：上一页最后一条是
id=12345，下一页就查WHERE id > 12345 ORDER BY id LIMIT 20 - 此时完全不需要
OFFSET，也不依赖总条数，性能稳定 - 缺点是不能跳页（比如直接点第 100 页），且要求排序字段绝对唯一、非空、有索引
- 如果你的列表按
created_at排序，注意用created_at DESC, id DESC组合防止时间相同导致顺序不稳
获取总页数时 rowCount() 为什么返回 0
很多人误以为对 SELECT COUNT(*) 执行 rowCount() 能拿到数字，其实它返回的是结果集行数（总是 1），而不是 COUNT(*) 的值本身。
必须调用 fetchColumn() 才能取出那个数字。
- 错误：
$total = $countStmt->rowCount(); // 得到 1 - 正确：
$total = (int)$countStmt->fetchColumn(); // 得到真实总数 - 如果
COUNT(*)查询没命中任何行（比如 WHERE 条件太严），fetchColumn()返回false或空字符串，务必转成(int)防止后续除零
游标分页绕不开这个细节：没有总页数概念，也就不用算；传统分页里，这个转换漏了会导致 ceil($total / $perPage) 出错。
