回表查询是MySQL因索引设计或SQL写法导致的性能瓶颈，PHP优化重点在于避免触发回表、减少回表代价；典型场景包括SELECT非索引列、ORDER BY/GROUP BY非索引列等；可通过覆盖索引、延迟关联及EXPLAIN验证优化。
回表查询本身不是 PHP 的问题，而是 MySQL（或其他关系型数据库）在执行某些查询时因索引设计或 SQL 写法导致的性能瓶颈。PHP 作为调用层，优化重点在于：**避免触发回表、减少回表代价、让数据库少走回头路**。
理解回表发生的典型场景
回表（Row Lookup / Bookmark Lookup）指：当使用非聚簇索引（如普通二级索引）查到主键值后，还需根据主键再回到聚簇索引（通常是主键索引）中查找其他未覆盖的字段数据。
常见触发条件：
- SELECT * 或 SELECT 包含了索引未包含的列（例如：在 name 字段建了索引，但查询 SELECT name, email FROM user WHERE name = 'xxx'，而 email 不在该索引中）
- WHERE 条件用了索引，但 ORDER BY 或 GROUP BY 涉及非索引列，导致无法使用索引排序，进而可能引发回表+临时表+文件排序
- 联合索引顺序不匹配查询需求（例如索引是 (a,b,c)，但只用 b 做 WHERE，或 WHERE a=1 ORDER BY c，b 未参与查询）
用覆盖索引消除回表
核心思路：让查询所需的所有字段都包含在同一个索引中，使 MySQL 直接从索引 B+ 树叶子节点拿到全部数据，无需回主键索引。
立即学习“PHP免费学习笔记（深入）”；
操作建议：
- 分析慢查询 SQL，明确 SELECT、WHERE、ORDER BY、GROUP BY 中涉及的所有字段
- 按「WHERE 等值字段 → WHERE 范围/IN 字段 → ORDER BY / GROUP BY 字段 → SELECT 非主键字段」顺序创建联合索引
- 例如：SELECT id, name, status FROM order WHERE user_id = 123 AND created_at > '2024-01-01' ORDER BY updated_at DESC；可建索引 (user_id, created_at, updated_at, id, name, status)
- 注意：索引字段不宜过多，避免写放大；TEXT/BLOB 类型不能直接建索引，需前缀或转换为生成列
合理使用延迟关联（Deferred Join）
当必须查多列但又难以全覆盖时，可先用最小索引快速定位主键，再用主键 IN 关联原表——把“多次随机回表”转为“一次有序回表”。
示例（MySQL）：
-- 低效（可能大量回表）
SELECT * FROM user WHERE status = 1 AND score > 80 ORDER BY created_at DESC LIMIT 20;
-- 优化：先查 ID，再关联取全量
SELECT u.* FROM user u INNER JOIN (
SELECT id FROM user WHERE status = 1 AND score > 80 ORDER BY created_at DESC LIMIT 20
) AS tmp ON u.id = tmp.id;
PHP 中只需拆成两步查询，或用子查询封装。适用于分页深、回表开销大、且主键有序性好的场景。
检查执行计划，确认是否真的回表
不要凭经验猜测，每次优化前用 EXPLAIN 验证：
- 看 type：ALL / index 是全扫描，容易回表；range / ref 较好；const / system 最优
- 看 key：是否命中预期索引
- 看 Extra：出现 Using filesort 或 Using temporary 往往伴随隐式回表；Using index 表示覆盖索引，无回表；Using index condition 是 ICP，可减少回表行数
- 在 PHP 中调试时，可在 PDO 执行前加
EXPLAIN前缀打印执行计划
