查得慢的四大原因是字段太宽、缓存没开、关联失控、索引缺失；须依次优化：精简field()、显式调用cache()、with()内裁剪字段、按WHERE顺序建联合索引。
查得慢，八成是这四个环节没对齐：字段太宽、缓存没开、关联失控、索引缺失。不是加 Redis 就能救，得一个个切口动刀。
Db::name('user')->field() 必须出现在 select() 之前
field() 不是“锦上添花”，是防止 MySQL 拉整行数据上来的第一道闸。尤其表里有 content、description 这类 TEXT 字段时，不指定字段，一次查 20 条就多传几 MB 数据。
-
field()必须写在select()或find()之前，链路断了就失效 - 字符串写法：
UserModel::field('id,nickname,create_time')->select()，逗号不能带空格 - 数组写法更安全：
UserModel::field(['id', 'nickname as name', 'avatar'])->select()，别名必须用键值对，'nickname'=>'name'才生效 - 排除字段用第二个参数
true：UserModel::field('content,remark', true)->select()，注意字段间不能有空格，否则第一个字段被截断
cache() 不是开关，是手动声明+手动清理的契约
ThinkPHP 的模型查询默认完全不走缓存，连 Redis 配好了也没用。调用 cache() 是显式签协议：这条 SQL 结果我认，缓存多久我定，改数据时我负责删。
-
cache()必须插在查询链中间，比如UserModel::where('status', 1)->cache(3600)->select() - 关联查询（
with()）和聚合函数（count()）不支持cache()直接挂载，会报错或缓存为空；得拆开：主表缓存 + 关联表单独缓存 - 缓存 key 默认是 SQL 的 MD5，极易冲突（换环境、加空格、改前缀都会变）；建议手写 key：
cache('user_active_list_202610', 3600) - 模型增删改后，必须主动
Cache::delete('user_active_list_202610')，否则缓存永远不更新
with() 的字段裁剪只能在闭包里写，且外键字段不能丢
很多人写 User::with('profile')->field('id,nickname')，以为能裁剪关联字段——这是无效的。field() 对关联表完全不识别，点号语法（如 profile.nickname）会被忽略或报错。
立即学习“PHP免费学习笔记（深入）”；
- 真正生效的位置只有两个：
with(['profile' => function ($q) { $q->field(['id', 'user_id', 'nickname']); }])，或者在模型关联方法定义里固化->field() - 外键字段（如
user_id）和关联模型主键（如id）必须显式包含，否则 ThinkPHP 绑定失败，profile返回空数组 - 多层关联（A→B→C）别堆
with('b.c')，容易 SQL 膨胀、内存爆掉；建议分步：先查 A 列表，再用where('id', 'in', $ids)批量查 B，再同理查 C - 只展示名称类字段（如角色名），用子查询比 JOIN 更轻：
->field('user.*, (SELECT name FROM role WHERE role.id = user.role_id) as role_name')
索引不是“加了就行”，要按 WHERE 条件顺序建联合索引
没索引的 where('mobile', $phone) 查一万条数据，平均延迟可能超 300ms；加了单列索引，where(['status'=>1, 'mobile'=>$phone]) 还是全表扫描——因为没覆盖全部条件。
- 先用
SHOW INDEX FROM user看mobile是否已有索引；没有就加：ALTER TABLE user ADD INDEX idx_mobile (mobile) - 复合条件优先建联合索引，顺序按「等值在前、范围在后」：
where(['status'=>1, 'create_time'=>['>=', $t]])→ADD INDEX idx_status_created (status, create_time) - 避免函数操作让索引失效：
where('DATE(create_time)', '2024-01-01')改成whereBetween('create_time', [$start, $end]) - RBAC 场景下，
auth_rule.name和auth_rule.status必须建联合索引：ADD INDEX idx_name_status (name, status)，否则每次权限校验都慢
最常被跳过的其实是字段裁剪和索引顺序——不是不知道，是查出来能用就停手了。但线上每多传 100KB 数据、每多一次全表扫描，都在把响应时间往临界点推。这些动作都不难，难的是每次写查询时都条件反射想一句：我到底需要哪几个字段？这个 WHERE 条件有没有索引兜底？
