慢查询核心在于“未走索引+扫描行数多”，而非单纯执行时间长；需用getrawsql()获取真实sql再执行explain分析type、key、extra三列，警惕隐式类型转换、前导like、函数包裹及联合索引顺序错误等索引失效场景。
慢查询不是“执行时间长”就等于“SQL有问题”，而是“没走索引+扫描行数多”才真卡。Yii 日志里写的 0.8s 只是总耗时，不告诉你扫了 200 万行还是 20 行——得看 EXPLAIN。
怎么拿到真实 SQL 并套 EXPLAIN
ActiveRecord 查询不能直接看日志里的占位符 SQL，WHERE id = ? 后面实际绑的是 9999999 还是 1，性能天差地别。
- 先用
$query->createCommand()->getRawSql()拿出带参数的原生 SQL（注意：不是日志里那条带问号的） - 再手动在数据库命令行或 phpMyAdmin 里执行
EXPLAIN SELECT ...，别信 Yii 的explain()方法返回值——它在 PostgreSQL 下默认不带ANALYZE，看不出真实执行开销 - 如果用 MySQL，
yii\db\Command::explain()可以用；但如果是复杂子查询或 UNION，还是手敲EXPLAIN FORMAT=JSON更准
EXPLAIN 里盯死这三列：type、key、Extra
type 是扫描方式，key 是实际用的索引，Extra 是隐藏代价。三者缺一不可：
-
type = ALL：全表扫描，基本等于没索引，优先处理 -
key为空：哪怕你建了idx_user_status_created，只要 WHERE 条件没按最左前缀写（比如只写了created_at > '2024-01-01'），MySQL 就不会用 -
Extra里出现Using filesort或Using temporary：ORDER BY / GROUP BY 字段没被索引覆盖，排序/分组被迫走磁盘临时表，比慢查询还伤
为什么加了索引还是慢？常见隐式失效场景
索引建了≠能用。很多“已优化”其实是假象，问题藏在类型和写法里：
- 字段是
INT，但 PHP 传参用了字符串：$query->andWhere(['user_id' => '123'])→ MySQL 隐式转类型，索引失效 -
LIKE '%abc'：前导通配符，B+ 树没法从头匹配，索引直接跳过 - 函数包裹字段：
WHERE YEAR(created_at) = 2024→ 索引字段被计算，无法下推 - 联合索引顺序反了：
INDEX (status, created_at)支持WHERE status = 1 AND created_at > '2024-01-01'，但不支持WHERE created_at > '2024-01-01'单独查
Yii 配置和代码层能立刻见效的检查点
有些慢，根本不用改 SQL，改两行配置或调用方式就能缓解：
- 数据库连接用
127.0.0.1代替localhost：PHP 默认走 Unix socket，某些系统 DNS 解析或权限策略会导致延迟飙升 - 查列表别用
ActiveRecord::find()->all()，改用asArray()：少一层对象映射，内存和 CPU 都省 20%+ - 避免 N+1：循环里调
User::findOne()是典型陷阱，改用User::findAll($ids)批量查，或用with('profile')预加载 - 开启查询缓存要谨慎：
Yii::$app->db->cache(...)对不变数据有效，但对实时性要求高的列表（如后台订单页）反而拖慢，因为缓存键管理本身有开销
真正卡住的往往不是单条 SQL 多慢，而是某次深分页（LIMIT 100000, 20）或某张表没索引却天天 COUNT(*)。别只盯着时间阈值，重点看 rows 和 key 列——它们不会说谎。
