唯一能看清底层执行效率的方式是直接在phpMyAdmin中执行带参数的Eloquent关联SQL并加EXPLAIN；需手动还原toSql()中的问号占位符，区分on()与where()位置，单独分析EXISTS子查询，并验证各层索引是否生效。
直接在 phpMyAdmin 里执行 Eloquent 生成的关联 SQL 并加 EXPLAIN，是唯一能看清底层执行效率的方式。Laravel 的 with()、whereHas() 或 leftJoin() 看似简洁，但一旦索引缺失、字段未选全或连接条件写错，就会触发全表扫描或临时表排序——这些在 Debugbar 里只显示“127ms”，根本看不出问题在哪。
把 Eloquent 关联查询转成可执行 SQL
toSql() 不会输出预加载语句，getQueryLog() 里的 sql 又带问号占位符，不能直接粘贴执行。必须手动还原参数，否则 phpMyAdmin 会报错或查不到数据。
- 用
vsprintf(str_replace('?', '%s', $query->sql), array_map(function ($b) { return is_string($b) ? "'".$b."'" : $b; }, $query->bindings))生成带值的 SQL（注意：数字和NULL不加引号） - 如果关联用了
with('user: id,name,email')，确保SELECT列表里包含外键（如user_id），否则 Laravel 匹配失败，但 SQL 本身能跑通——这会导致你误判性能问题 - 对
whereHas()生成的EXISTS子查询，不要只看主查询的EXPLAIN，得单独把子查询拎出来也跑一遍EXPLAIN，它可能比主表还慢
LEFT JOIN 关联慢？重点检查 ON 和 WHERE 的位置
Laravel 的 leftJoin() 回调里混用 on() 和 where() 是高频陷阱。写在 where() 里的条件会被下推到 ON 还是变成 WHERE 后过滤，取决于构建器版本和写法，但 phpMyAdmin 里的 EXPLAIN 会立刻暴露差异。
- 正确写法：所有用于关联匹配的字段（如
itm.skuID = isku.ID）和关联表过滤条件（如itm.coID = 4）都放进on()链式调用 - 错误写法：在
leftJoin()回调里用where('itm.coID', 4)—— 这会让 MySQL 先做笛卡尔积再过滤，EXPLAIN显示type: ALL和巨大rows - 验证方式：对比
toSql()输出的 SQL 和你手写的规范 SQL，看ON子句是否包含全部关联+过滤逻辑
预加载失效时，phpMyAdmin 能帮你定位是哪一层断的
你以为写了 with(['comments.user']) 就好了，结果日志里还是冒出几十条 select * from users where id in (1,2,3...)。这不是 Laravel bug，而是某一层没加载成功，导致后续访问又触发懒加载。
立即学习“PHP免费学习笔记（深入）”；
- 先在 phpMyAdmin 执行预加载主查询（如
select * from posts where status = 'published'），记下返回的id列表 - 再手动构造预加载 SQL：比如
select * from comments where post_id in (1,2,3...)，看是否走索引；如果不走，说明post_id缺少索引 - 接着查
select * from users where id in (…)，确认users.id是主键且类型匹配（别用字符串 UUID 当外键，InnoDB 会锁整页） - 如果两层 SQL 都快，但 Laravel 里还是 N+1，大概率是模型里漏写了
protected $fillable或用了select()截断了外键字段
最麻烦的是那些跨三张表、带 orWhere() 和聚合函数的关联查询——phpMyAdmin 的 EXPLAIN 会清楚告诉你是否用了 Using temporary 或 Using filesort，但修复它需要改 Laravel 代码结构，不是加个索引就能解决的。
