PHP 中数据库复杂查询性能差，核心问题往往不在 PHP 代码本身，而在 SQL 设计、索引使用和数据访问模式。优化关键在于让数据库少扫描、快定位、少传输。
精准设计 WHERE 条件，避免全表扫描
复杂查询常因条件松散导致 MySQL 放弃索引。确保 WHERE 子句中参与过滤的字段有对应复合索引，且遵循最左前缀原则。例如查询：
SELECT * FROM orders JOIN users ON orders.user_id = users.id WHERE users.status = 'active' AND orders.created_at > '2024-01-01' ORDER BY orders.amount DESC LIMIT 20;
若经常按 status + created_at 过滤，应在 users 表建 (status, id) 索引（因 JOIN 依赖 user_id），在 orders 表建 (created_at, user_id, amount) 索引（覆盖排序与关联）。
- 避免在索引列上用函数或计算，如 WHERE DATE(created_at) = '2024-01-01' 会失效；改用 created_at >= '2024-01-01' AND created_at
- 少用 OR 连接不同字段条件，优先拆成 UNION 或确保每个分支都能走索引
- 区分 IN 和 EXISTS：子查询结果集小时用 EXISTS，大且有索引时 IN 更稳
用覆盖索引减少回表，限制返回字段
SELECT * 是复杂查询慢的常见原因——不仅传输多，还强制回表取未索引字段。应只查真正需要的列，并让这些列尽可能被索引“覆盖”。
- 把常用查询字段加入索引末尾，例如查询常要 user_id, status, name, email，可建索引 (user_id, status, name, email)
- 在 JOIN 查询中，检查 EXPLAIN 输出的 Extra 列：出现 Using index 表示覆盖索引生效；若为 Using where; Using temporary; Using filesort，说明需优化条件或添加排序字段到索引
- PHP 中用 PDO::FETCH_ASSOC 明确取关联数组，避免 FETCH_BOTH 带来双倍内存开销
分页与深度分页必须加游标或延迟关联
OFFSET 越大，MySQL 越要跳过前面所有行，复杂 JOIN 下性能断崖式下降。例如 LIMIT 10000, 20 实际扫描 10020 行再丢弃前 10000 行。
立即学习“PHP免费学习笔记（深入）”；
- 用游标分页（Cursor-based Pagination）：记录上一页最后一条的排序字段值（如 last_amount = 8900），下一页查 WHERE amount
- 对多表关联分页，先用子查询只取主表 ID，再 JOIN 补全数据，即“延迟关联”：
SELECT o.*, u.name FROM orders o INNER JOIN (SELECT id FROM orders WHERE status='shipped' ORDER BY created_at DESC LIMIT 20 OFFSET 10000) AS tmp ON o.id = tmp.id INNER JOIN users u ON o.user_id = u.id; - 对实时性要求不高的列表，考虑用缓存分页结果（如 Redis 存 ID 列表），避免每次重算
合理拆分与缓存，避开单次“巨查询”
一个含 5 张表 JOIN、多个子查询、GROUP BY + HAVING 的语句，不仅难优化，还容易锁表、拖慢整体响应。不如拆成逻辑清晰的几步。
- 把统计类子查询（如用户订单总数、最近评论）单独执行，PHP 合并结果；比在 SQL 里写多个 COUNT(*) OVER() 更可控
- 高频但低频更新的数据（如商品分类树、地区列表）用 APCu 或 Redis 缓存完整结构，PHP 层组装，绕过 JOIN
- 对报表类复杂查询，提前物化中间结果到汇总表（如每天凌晨跑 ETL 写入 order_daily_summary），查时直接 SELECT 单表
