ThinkPHP数据库优化核心是规范分层与精准干预：模型专注数据逻辑，控制器禁拼SQL，视图不触数据库；精简字段、消灭N+1、合理建索引（遵循最左前缀）、善用with预加载与field指定字段、结合缓存策略按需控制生命周期。
ThinkPHP用MVC架构做数据库交互，核心不在“分层”，而在让每一层各司其职、不越界——模型管数据逻辑，控制器只调度、不拼SQL，视图绝不碰数据库。低效查询往往不是框架慢，而是写法绕开了它的优化机制。
精简字段，别让MySQL多读一个字节
全字段查询（select()不指定字段）在列表页尤其危险。遇到TEXT或JSON字段，不仅拖慢查询，还增加网络传输和PHP内存压力。
- 列表页只查真正要展示的字段：比如
$users = Db::name('user')->field('id,username,nickname,status,create_time')->select(); - 详情页再按需加载扩展字段，用
find()或单独field()补足，避免一次拉全表 - ThinkPHP5/6中，
field()是轻量级干预，比写原生SQL更安全，也更容易被缓存识别
消灭N+1，用一次查询代替十次循环
典型场景：查出100个用户，再对每个用户查一遍角色名——这就是N+1。它把数据库从“一次批量读”变成“101次单行读”，响应时间直接翻倍。
- 两层关联（如User → Role）优先用
with('role')，但必须确保role_id有索引，否则JOIN会全表扫描 - 三层及以上（如User → Role → Permission），改用批量ID预查：先取所有
role_id数组，再where('id', 'in', $ids)一次性查完 - 仅需关联字段值（如角色名），可用子查询字段：
->field('user.*, (SELECT name FROM role WHERE role.id = user.role_id) AS role_name')，避免额外JOIN开销
索引不是建了就有效，得匹配查询习惯
索引失效常因写法“看着合理，实则跳过索引”。ThinkPHP链式调用容易掩盖底层SQL风险。
立即学习“PHP免费学习笔记（深入）”；
- 联合索引顺序必须贴合WHERE条件：等值字段（
status=1）放最左，范围字段（create_time >= ?）居中，排序字段（ORDER BY id）靠右 - 禁用左模糊：
like '%abc'→ 改用右模糊like 'abc%'或全文索引 - 避免函数操作字段：
YEAR(create_time)=2024→ 改为范围查询：whereBetween('create_time', ['2024-01-01', '2024-12-31']) - 验证是否真生效：开启
'sql_explain' => true，看EXPLAIN结果中key是否命中、rows是否明显小于总行数
缓存不是开关，是策略选择
缓存不是“打开就快”，而是判断哪些数据值得缓、缓多久、怎么更新。配置项开缓存，不如业务层主动控制。
- 变动少的数据（分类、地区、配置）直接加
cache(true, 3600)，1小时不过期 - 需要手动管理生命周期的，用带标识的缓存：
cache('category_list', 3600)，方便后续主动Cache::delete('category_list') - 高频且实时性要求高的（如用户登录态、购物车），别走查询缓存，改用
Cache::get()+ 业务逻辑刷新 - Redis作缓存驱动比文件更快，尤其在并发场景下，ThinkPHP6已原生支持无缝切换
