N+1查询是性能瓶颈主因，需通过启用查询日志（如DB::enableQueryLog或error_log记录SQL）、使用Debugbar标红识别、检查模板/控制器中循环内访问关联属性或重复查配置等行为快速定位。
直接结论：不是加缓存或换服务器，而是先砍掉“隐性循环查询”——90% 的堆积来自 N+1 查询、重复配置加载、未合并的关联查询。
怎么快速识别 N+1 查询（尤其在 ThinkPHP/Laravel 风格项目中）
老项目里最隐蔽的 SQL 堆积，是模板层或控制器里“看着只查一次，实际每循环一次就多一条 SELECT”。比如：
- 遍历用户列表时，对每个
$user调用$user->profile或$user->orders()，而没做预加载 - 在
foreach里写Db::name('config')->where('key', $k)->value('val')，查了 20 次配置表 - 用
find()查主记录后，又在循环里对每个 ID 单独select * from logs where user_id = ?
验证方法：在入口文件顶部加 define('SQL_LOG_ENABLED', true)，然后在数据库连接封装层（如 Db::execute() 或 PDO::query() 前）插一句：error_log("SQL: " . $sql, 4)。请求一跑，错误日志里立刻暴露重复模式。
ThinkPHP 3.2 / CodeIgniter 2.x 怎么安全地合并查询
这些老框架不支持现代 ORM 的 with()，但可以手动合并。关键不是“能不能”，而是“要不要改底层封装”：
立即学习“PHP免费学习笔记（深入）”；
- 把多次单 ID 查询改成
IN：原逻辑Db::name('user')->find($id)× 50 → 改成Db::name('user')->where('id', 'in', $idList)->select() - 关联数据用一次
JOIN拉全：比如用户 + 角色 + 部门，别分三次查，写成SELECT u.*, r.name as role_name, d.name as dept_name FROM user u LEFT JOIN role r ON u.role_id=r.id LEFT JOIN dept d ON u.dept_id=d.id WHERE u.id IN (?) - 避免在模型的
_initialize()或构造函数里自动查配置、权限、菜单——这些该由统一服务层一次性加载并注入，而不是每个模型实例都查一遍
为什么 cache(true) 在老项目里经常失效
ThinkPHP 的 cache(true) 默认用文件缓存，而老项目常存在两个硬伤：
- 缓存键生成依赖
__FILE__和行号，一旦代码微调（比如加个空行），缓存就失效，等于没开 - 没清理旧缓存目录，
runtime/cache/下堆了几万个小文件，file_exists()检查本身变瓶颈 - 缓存时间设成
0（永久）或3600（1 小时），但业务数据其实 5 分钟就变，导致缓存击穿 + 大量并发重建
实操建议：临时把缓存切到 Redis（哪怕本地装个 redis-server），用 Db::name('xxx')->cache(true, 300, 'redis')；同时删掉所有 cache(true) 里没指定过期时间的调用。
最容易被忽略的“伪单次查询”陷阱
有些查询看似只执行一次，实则每次请求都在重复干重活：
-
Db::name('menu')->order('sort')->select()放在公共模板里，但菜单几乎不变 → 应该在部署时生成静态 PHP 数组，或用include 'runtime/menu.php' - 每个请求都查
SELECT * FROM sys_config WHERE type='site'，而它只有 3 条记录 → 直接读配置文件或常量数组 - 登录态校验里反复查
session_id对应的用户信息，却没利用 PHP 自带的$_SESSION存用户 ID，导致每次都要 DB 回源
真正要砍的，从来不是“大查询”，而是那些藏在 include、extends、__get 魔术方法里的小查询——它们不报错、不慢、但数量爆炸。盯住日志里出现频次最高的那几条 SQL，比优化某条耗时 200ms 的慢查询更有效。
