Laravel关联查询慢的根本原因是索引缺失或设计不当，需先用EXPLAIN分析真实SQL，再按“等值条件在前、范围条件在后”创建复合索引，并确保外键、软删除字段及SELECT字段均被覆盖。
直接在 phpMyAdmin 里加索引不能解决 Laravel 关联查询慢的问题——它只是执行工具，真正起作用的是你加了什么索引、加在哪儿、顺序对不对。
查清哪些字段真在 WHERE / JOIN 中被用到
很多人一上来就给 user_id 加单列索引，结果查询还是慢。因为实际 SQL 是 WHERE status = 'published' AND created_at > '2025-01-01'，而你只建了 status 索引，created_at 字段根本没走索引。
- 在 Laravel 开发环境开启查询日志：
DB::enableQueryLog()，然后跑一次典型请求，再dd(DB::getQueryLog())拿到真实 SQL - 把那条 SQL 粘贴进 phpMyAdmin 的 SQL 标签页，点“分析”（或执行
EXPLAIN命令），重点看key列是否为NULL、rows是否远大于实际返回数 - 注意外键字段名是否和模型里定义的一致：比如
Post::belongsTo(User::class, 'author_id')，那就要查author_id，不是user_id
在 phpMyAdmin 中建复合索引要按“等值前置、范围后置”
phpMyAdmin 的索引创建界面不提示字段顺序影响，但 MySQL 会严格按你填写的顺序匹配。错一位，整个索引就几乎失效。
- 如果查询是
WHERE category_id = 5 AND status = 'active' AND created_at > '2025-06-01'，索引字段顺序必须是(category_id, status, created_at)，不能把created_at放前面 - 在 phpMyAdmin 表结构页点“索引”，填字段时手动拖拽调整顺序，或删掉重来——它默认按你点击添加的顺序排，不是按字母
- 软删除字段
deleted_at如果常出现在 WHERE 条件里（比如whereNull('deleted_at')），必须包含在复合索引里，且放在最后；否则 MySQL 无法使用该索引做范围扫描
外键字段没索引？phpMyAdmin 里一眼就能看出
Laravel 的 foreignId() 不自动建索引，而 phpMyAdmin 的“关系视图”只显示外键约束，不显示索引状态——这两者完全无关。你得手动确认。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
立即学习“PHP免费学习笔记（深入）”；
- 进表结构页，看“索引”标签下有没有对应外键字段（如
post_id、comment_id）的行；没有就说明没索引 - JOIN 慢十倍以上，大概率是这里漏了。哪怕只加一个
INDEX(post_id)，LEFT JOIN 性能也可能从 2s 降到 50ms - 不要依赖 phpMyAdmin 的“外键”标签页判断性能——它只管约束完整性，不管查询快慢
别在 phpMyAdmin 里瞎试“覆盖索引”，先验证字段是否真被 SELECT
有人听说“覆盖索引快”，就给 (user_id, name, email) 建联合索引，结果发现没提升。因为 Laravel 查询里压根没 select('name', 'email')，而是 select(*) 或没指定字段，MySQL 依然要回表读完整行。
- 先改 Laravel 代码：关联预加载时显式限制字段，例如
with(['user' => function ($q) { $q->select('id', 'name'); }]) - 再在 phpMyAdmin 里建对应索引：
(user_id, id, name)（注意user_id是 JOIN 条件，必须放最前） - 建完立刻用
EXPLAIN对比：如果Extra出现Using index，说明命中了覆盖索引；如果还是Using where; Using temporary; Using filesort，说明索引没用对
最常被忽略的点：phpMyAdmin 显示“索引已存在”，不代表它被当前查询用上；EXPLAIN 结果里的 key_len 才告诉你实际用了索引的前几个字节——比如你建了 (a, b, c)，但 key_len 只有 4，说明只用了 a，后面两个字段完全没参与。
