根本原因是查询设计不合理：select * 加 limit offset, size 再加全量 fetch_all() 三者叠加，导致mysql扫描冗余行、网络传输膨胀、php内存溢出；应改用游标分页、覆盖索引、逐行处理及缓存兜底。
PHP 处理大数据量查询卡顿、内存溢出、响应超时，根本原因不是 PHP 本身慢，而是查询设计和数据加载方式不合理——SELECT *、LIMIT offset, size、全量 fetch_all() 这三者叠加，是生产环境最常触发 OOM 和慢查询的组合拳。
为什么 LIMIT offset, size 在页码大时越来越慢
MySQL 的 OFFSET 不是跳索引位置，而是真实扫描并丢弃前 N 行。查第 1000 页（OFFSET 20000）时，即使只取 20 条，也要先读走两万行。EXPLAIN 里 rows 持续飙升，Extra 出现 Using filesort 或 Using temporary 就是典型信号。
- 必须确保
ORDER BY字段有索引，否则直接退化为全表扫描 - 避免在
ORDER BY中混用ASC/DESC，MySQL 8.0 前无法高效利用复合索引 -
SELECT *会放大问题：每多传 1KB 冗余字段，10 万行就多扛 100MB 网络流量，mysqli_fetch_all()很可能直接 OOM
游标分页怎么写才不翻车
用上一页最后一条记录的排序值作为下一页起点，绕过 OFFSET 扫描，但细节错一点就失效。
- 游标值必须唯一且非空，优先选主键；别用
created_at（可能重复），更别用status这类低区分度字段 - 升序用
WHERE id > ?，降序用WHERE id ，SQL 必须保持 <code>ORDER BY方向一致 -
$_GET['cursor']必须强转：(int)$cursor或filter_var($cursor, FILTER_VALIDATE_INT)，否则传入字符串或负数可能触发全表扫描 - 游标值不能裸露传前端，需
base64_encode()或dechex()转义，防止 URL 截断或注入
PHP 层怎么避免内存爆掉
不是调大 memory_limit 就完事——那是把火警器关掉，不是灭火。
- 禁用全量加载：永远不用
fetch_all()拿百万行，改用while ($row = $stmt->fetch(PDO::FETCH_ASSOC))逐行处理 - 批量处理时每批结束后手动清理：
unset($batch);+gc_collect_cycles();，尤其在长循环中 - 对超大结果集，启用未缓冲查询：
$pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false);，配合逐行 fetch - 如果只是导出或统计，考虑用
mysqlnd的mysqli_use_result()，跳过客户端缓存
哪些场景还不得不硬扛 OFFSET
游标分页不适用所有业务，强行套用反而引入新问题。
- 用户手动输入页码（如后台管理页跳转到第 87 页）、Excel 导出指定范围、按条件筛选后翻页——这些需要随机访问能力
- 必须用
OFFSET时，先用覆盖索引查 ID：SELECT id FROM table WHERE ... ORDER BY id LIMIT 50000, 20，再用这些 IDIN关联主表 - 热门页（如前 50 页）可预热进 Redis：
SET page:users:30 "..." EX 60，冷页再走游标兜底 - 绝对不要让
OFFSET超过 10 万，超过就该切分逻辑或加缓存层
真正容易被忽略的是排序字段的稳定性：如果游标依赖的字段（比如 updated_at）在分页过程中被并发更新，会导致漏数据或重复。主键最安全，时间戳次之，但必须配唯一约束或组合索引兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
