90%的PHP数据库性能问题源于SELECT *、缺失索引和N+1查询三类可立即修复的写法；应优先开启慢查询日志并用EXPLAIN分析，聚焦type=ALL、key=NULL、rows过大等问题，按“先查慢查询、再加索引、最后改代码”顺序优化。
直接说结论：90% 的 PHP 数据库性能问题，不来自服务器配置或框架本身，而来自 SELECT *、缺失索引、N+1 查询这三类可立即修复的写法。优化优先级应是「先查慢查询，再加索引，最后改代码」，不是一上来就换 Redis 或分库。
怎么定位真正拖慢页面的 SQL？
靠猜没用，得看实际执行耗时。PHP 应用里最有效的办法是开启 MySQL 的慢查询日志，并配合 EXPLAIN 分析关键语句。
- 在 MySQL 配置中设置
slow_query_log = ON、long_query_time = 1（单位秒），重启服务后，所有超时查询会记录到日志文件 - 对首页、列表页等高频接口，在 PHP 中临时加上
EXPLAIN SELECT ...输出执行计划，重点关注type是否为ALL（全表扫描）、key是否为NULL（未用索引）、rows是否远大于实际返回行数 - 避免只看「页面加载时间」——可能是网络、模板渲染或第三方 API 拖慢的，必须把数据库响应时间单独剥离出来（比如用
microtime(true)包住$pdo->query()）
哪些字段必须加索引？
不是所有 WHERE 条件都值得建索引，重点盯住高频、低选择性、参与 JOIN 或 ORDER BY 的列。复合索引顺序很关键，要匹配查询条件的最左前缀。
- 必加场景：
WHERE status = ? AND catid = ?→ 建复合索引(status, catid)；但WHERE catid = ?单独查也能命中该索引，WHERE status = ?就不能 - 警惕失效操作：在 WHERE 中对字段用函数，如
WHERE DATE(create_time) = '2024-01-01'，会导致索引完全失效；应改写为WHERE create_time >= '2024-01-01 00:00:00' AND create_time - 别盲目加索引：单表索引总数建议控制在 5 个以内；写多读少的表（如日志表）加索引反而拖慢
INSERT
为什么 foreach 里写 query 是性能杀手？
这就是典型的 N+1 查询问题：1 次查出 ID 列表，再循环 N 次查详情。网络往返 + 查询解析 + 执行开销叠加，比单次 JOIN 或 IN 查询慢 3–10 倍。
立即学习“PHP免费学习笔记（深入）”；
- 反例：
foreach ($ids as $id) { $db->query("SELECT title, content FROM article WHERE id = $id"); } - 正解 1（批量 IN）：
$db->query("SELECT id, title, content FROM article WHERE id IN (".implode(',', $ids).")")，再用array_column($rows, null, 'id')构建映射 - 正解 2（JOIN 预加载）：如果关联用户信息，不要循环查
user_id，改用LEFT JOIN user ON article.user_id = user.id - 注意 IN 参数上限：MySQL 默认
max_allowed_packet限制单次查询大小，ID 过多时需分批（如每 500 个一组）
缓存不是万能解药，但有些数据真没必要查库
缓存适合「读多写少 + 变更可预测」的数据，比如导航菜单、站点配置、分类树。但缓存策略错了，反而引入一致性 bug 和内存泄漏。
- 优先用 APCu：PHP 进程内共享内存，无网络开销，适合单机部署的配置类数据；
apcu_store('site_config', $config, 3600) - Redis 适合跨进程/多机器场景，但别缓存整张用户表——缓存粒度越细越好，比如只缓存
user:123:profile - 千万别缓存「实时性要求高」的数据（如订单状态、库存），除非你有可靠的失效机制（如写库时主动
del user:123:profile） - 缓存 key 要带版本号或更新时间戳，避免旧缓存长期不刷新，例如
"article_list_v2_202605"
最容易被忽略的一点：索引不是建完就一劳永逸的。表数据量翻倍、查询模式变化、MySQL 版本升级后，原来高效的索引可能变成负担。至少每季度用 ANALYZE TABLE 更新统计信息，大表定期 OPTIMIZE TABLE 整理碎片——这些操作在低峰期几秒钟就能完成，但效果立竿见影。
