mysql分页用limit和offset时，offset越大性能越差，因其需扫描并丢弃前n行；应确保order by字段有索引、校验offset参数、避免深分页，推荐游标分页替代。
LIMIT 和 OFFSET 是 MySQL 分页最直接的实现方式，但直接套用容易出错——尤其是 OFFSET 值变大时性能会断崖式下降。
为什么 OFFSET 越大越慢？
MySQL 在执行 OFFSET 10000 时，并不是跳过前 10000 行再取数据，而是先扫描并丢弃前 10000 行结果，再返回后续行。这意味着分页越靠后，扫描量越大，I/O 和 CPU 开销越高。
- 表有 100 万行，
OFFSET 500000实际要读取至少 50 万 +LIMIT行 - 若未命中索引，还可能触发全表扫描
- 高并发下容易堆积慢查询，拖垮整个数据库
如何写一个安全可用的分页 SQL？
基础结构必须带排序和主键/唯一索引约束，否则分页结果可能重复或遗漏：
SELECT * FROM users WHERE status = 1 ORDER BY id ASC LIMIT 20 OFFSET 40;
关键点：
-
ORDER BY字段必须有索引（如id是主键，天然有索引） - 避免用
ORDER BY created_at这类可能重复的字段做分页锚点，除非加id作为第二排序条件 -
OFFSET值需校验：不能为负数，不能超过总行数（建议前端传参时就限制最大页码） - PHP 中拼接前务必用
intval()或filter_var($offset, FILTER_VALIDATE_INT)过滤
PHP 中如何计算和传递分页参数？
不要依赖“当前页 × 每页条数”硬算 OFFSET，而应从请求中明确接收 limit 和 offset（或 page），并做防御性处理：
- 用
$_GET['limit'] ?? 20获取每页数量，上限建议设为 100，防止恶意拉取大量数据 -
$_GET['offset'] ?? 0必须max(0, intval($_GET['offset']))处理 - 查询总数用
SELECT COUNT(*)单独执行（注意：不要用SQL_CALC_FOUND_ROWS，已废弃且不准） - 若总数超 10 万，可考虑不显示总页数，改用“下一页是否存在”逻辑（查
LIMIT $limit + 1，只取前 $limit 行，多出来那 1 行判断是否有下一页）
什么时候该放弃 OFFSET？
当用户明显进入深分页（比如 OFFSET > 10000），或者业务允许“游标分页”时，应切换方案：
- 用上一页最后一条记录的
id作为下一页起点：WHERE id > 12345 ORDER BY id ASC LIMIT 20 - 游标分页无法跳转任意页，但性能稳定、无偏移累积误差
- 对时间线类数据（如动态、日志），用
created_at+id组合游标更自然 - PHP 中需把游标值（如
12345）作为next_cursor返回给前端，而不是page=501
OFFSET 看似简单，但真实系统里最容易在高偏移、无索引、未过滤参数这几个点上翻车。真正要稳，得从 SQL 结构、PHP 参数校验、前端交互逻辑三处同时卡住。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
