用 where id > ? 替代 limit offset, size 可避免百万级偏移量超时：因后者需扫描并丢弃前 offset 行，而游标分页基于有序索引字段恒定性能，仅适用于连续翻页且需唯一有序索引。
直接跳转到百万级偏移量会超时？用 WHERE id > ? 替代 LIMIT offset, size
当 offset 超过 10 万，MySQL 的 LIMIT 100000, 20 会强制扫描前 10 万行再丢弃，CPU 和 I/O 压力陡增，PHP 进程常因超时中断。真实场景中，用户根本不会手动翻到第 5000 页，但爬虫或导出接口可能触发这种查询。
改用「游标分页（cursor-based pagination）」：假设按 id 升序，第一页查 SELECT * FROM table ORDER BY id ASC LIMIT 20，拿到最后一条的 id = 12345；下一页就查 SELECT * FROM table WHERE id > 12345 ORDER BY id ASC LIMIT 20。这种方式不依赖偏移量，无论翻到第几页，都是恒定性能。
- 必须有唯一、有序、非空的字段（如自增
id或时间戳created_at），且该字段上有索引 - 不能支持「跳转任意页码」，只适合「下一页/上一页」连续浏览场景
- 若需双向翻页（上一页），用
WHERE id ，注意结果要再反转顺序
总记录数 COUNT(*) 在千万级表里太慢？用近似值或缓存替代
分页控件常需要显示「共 N 条」，但对大表执行 SELECT COUNT(*) FROM huge_table 可能耗时数秒甚至分钟，且并发高时易锁表。这不是 PHP 层能优化的问题，得绕开它。
实际业务中，用户并不关心精确总数——他们只关心「是否还有下一页」。所以可改用 SELECT COUNT(*) FROM (SELECT 1 FROM table WHERE ... ORDER BY id LIMIT 21) t：只查最多 21 条，够判断是否有下一页即可。或者更彻底地，去掉总数显示，只保留「下一页」按钮，点击后查不到数据再提示「到底了」。
立即学习“PHP免费学习笔记（深入）”；
稻草人企业站管理系统基于php+sqlite与php+mysql两个版本，php+sqlite特点和asp+access差不多,优点是利于备份，现在大多网站空间都支持php+sqlite。php+mysql特点是利于处理大量的数据，但备份和还原不方便。 网站特点： 1、程序分为php+sqlite、php+mysql两个版本 2、程序采用php+smarty模板技术 修改模板方便 3、程序采用面
- 如果真要总数，可定期用
SHOW TABLE STATUS查table_rows字段（MyISAM 准确，InnoDB 是估算值） - 对统计要求严格的场景，用单独的计数表或 Redis
INCR维护，写操作时同步更新 - 避免在分页接口里同时查数据和总数，拆成两个独立请求或异步加载总数
PHP 代码里手写 SQL 拼接分页参数？用 PDO 预处理 + 显式类型转换
常见错误是把用户传入的 page 和 size 直接拼进 SQL，既不校验也不转义，导致注入或类型错乱。例如 $sql = "LIMIT " . $_GET['offset'] . ", " . $_GET['size']，传入 offset=0; DROP TABLE users; 就完蛋。
正确做法是：用 intval() 强制转整型，并设合理上下限；size 严格限制最大值（如不超过 100）；最终仍走 PDO 预处理（虽然 LIMIT 不能用占位符，但参数本身已安全）：
$page = max(1, min(10000, intval($_GET['page'] ?? 1)));
$size = max(10, min(100, intval($_GET['size'] ?? 20)));
$offset = ($page - 1) * $size;
$stmt = $pdo->prepare("SELECT * FROM article WHERE status = ? ORDER BY id DESC LIMIT ?, ?");
$stmt->execute([1, $offset, $size]);-
LIMIT参数不能用?占位符（PDO 不支持），但变量经intval()后可安全拼接 - 永远限制
$page和$size的取值范围，防暴力遍历或内存溢出 - 不要信任前端传来的
offset，必须从page和size重新计算
ES 或 Redis 能替代 MySQL 分页？看场景，别盲目上重武器
有人一遇到慢分页就想到「上 Elasticsearch」，但 ES 的 from + size 同样有深度分页问题（默认上限 10000），且同步延迟、运维成本高。Redis 的 ZSET 倒适合按分数排序的轻量分页（如热搜榜），但不适合关联复杂查询。
真正该考虑中间层的场景只有两个：一是搜索类需求（全文检索+相关性排序），二是读多写少、结构固定、允许秒级延迟的排行榜类分页。其余情况，优先优化 MySQL 查询和索引，比换存储更稳更快。
- 给分页字段加联合索引，例如
ORDER BY status, created_at DESC就建INDEX(status, created_at) - 避免
SELECT *，只查必要字段，减少网络和内存开销 - 单次分页返回超过 50 条数据，大概率说明前端设计有问题，而不是后端没优化好
游标分页的边界条件（比如删除中间数据导致漏行、并发插入导致重复）容易被忽略，上线前必须用真实数据压测翻页逻辑。
