在Yii中调试慢查询需先用getRawSql()获取带实际参数的完整SQL，再在MySQL中执行EXPLAIN分析；重点检查type列（ALL/index需优化）、Extra列（Using filesort/temporary需避免）及key与possible_keys是否匹配。
在Yii框架中调试慢查询时，必须看清数据库底层到底怎么执行SQL——直接在MySQL里跑EXPLAIN是基础，但Yii生成的SQL常带参数绑定、自动JOIN和动态WHERE，手动拼接容易出错，导致执行计划失真。
获取Yii实际生成的SQL语句
第一步不是直接加EXPLAIN，而是先拿到Yii真正发给数据库的完整SQL。使用createCommand()后调用getRawSql()，它会把所有占位符替换成当前绑定值（注意：仅限调试环境，生产环境禁用）。
例如：$sql = Yii::$app->db->createCommand($query)->getRawSql();
【必须确保查询已绑定全部参数】，否则getRawSql()返回的SQL含问号，无法被MySQL解析；未绑定参数时强行执行EXPLAIN会报语法错误。
在MySQL命令行中执行EXPLAIN
复制上一步得到的完整SQL，在MySQL客户端前缀加上EXPLAIN，回车执行：
EXPLAIN SELECT `id`, `name` FROM `user` WHERE `status` = 1 AND `created_at` > '2025-01-01';
这一步操作起来很简单，直接把生成的SQL粘贴进去就行。别忘了末尾加分号。
重点看type和Extra列是否踩坑
方法一：快速判断性能瓶颈
盯住type列——如果出现ALL或index，说明走了全表扫描或全索引扫描，99%需要加索引或改写WHERE条件。
方法二：揪出隐藏开销
检查Extra列——一旦看到Using filesort或Using temporary，立刻停手优化，这两个标志意味着MySQL不得不额外排序或建临时表，哪怕rows显示只有几十行，真实耗时也可能飙升。
方法三：验证索引是否真被用上
对比possible_keys和key两列：如果possible_keys非空但key为NULL，说明优化器主动弃用了可用索引，大概率是WHERE条件存在函数包裹（如DATE(created_at)）或类型隐式转换（如字符串字段查整数）。
在Yii中嵌入EXPLAIN并结构化解析
第一步：封装一个调试辅助方法
在任意Helper类中加入：
public static function explain($query) { $sql = Yii::$app->db->createCommand($query)->getRawSql(); return Yii::$app->db->createCommand("EXPLAIN $sql")->queryAll(); }
第二步：传入ActiveQuery对象转成SQL
对User::find()->where(['status' => 1])->orderBy('id DESC')这类ActiveQuery，先调->createCommand(Yii::$app->db)->getRawSql()再喂给上面函数。
第三步：用var_dump()或日志输出结果数组，逐行对照type、key、rows值——别只看第一行，多表JOIN时每张表一行记录，要挨个检查。
