怎样在Navicat中通过执行计划排查Nested Loop性能瓶颈？-navicat-PHP中文网

有Using join buffer (Block Nested Loop)说明未走索引，正用低效BNL；无该提示且type为ref/eq_ref、key非空，才是健康的Index Nested-Loop Join（INLJ）。

怎样在navicat中通过执行计划排查nested loop性能瓶颈？

直接看 EXPLAIN 输出里有没有 Using join buffer (Block Nested Loop) —— 有，说明没走索引驱动，正用低效的 BNL；没它、且 type 是 ref/eq_ref、key 非空，才是健康的 Index Nested-Loop Join（INLJ）。

Navicat里怎么快速打开执行计划

在 Navicat 的 SQL 编辑器中写好查询后，别直接点“运行”，点工具栏上的 “解释”按钮（图标像放大镜+齿轮） 或按快捷键 Ctrl+Shift+E（Windows）/Cmd+Shift+E（macOS）。它会自动在下方面板显示 EXPLAIN 结果表格，不是图形化流程图，是标准 MySQL 的文本执行计划。

注意：Navicat 不会默认执行 EXPLAIN FORMAT=JSON，如需确认驱动表顺序，得手动在编辑器里输入完整命令：

EXPLAIN FORMAT=JSON SELECT * FROM orders o JOIN users u ON o.user_id = u.id;

然后在结果面板里找 "leading_table" 字段值。

关键三列怎么看：type / key / Extra

聚焦被驱动表那行记录（通常是 JOIN 语句中右边的表），检查这三项是否同时满足：

type 是 ref、eq_ref 或 const —— 表示用了索引做等值查找
key 列显示具体索引名（比如 PRIMARY 或 idx_user_id），不能是 NULL
Extra 里不含 Using join buffer (Block Nested Loop) —— 这个出现就代表退化成全表扫描匹配

只要其中任一不满足，当前 Nested Loop 就大概率没走 INLJ，而是 Block Nested Loop（BNL），性能会断崖式下降。

navicatmysql

Navicat For MySQL

下载

为什么加了索引还是显示 `key` 为空？常见掉坑点

索引建了但执行计划不认，多数不是 MySQL 问题，而是隐式条件破坏了索引可用性：

字段类型不一致：比如 orders.user_id 是 INT，users.id 是 VARCHAR，JOIN 时会触发隐式转换，索引失效
字符集或排序规则不同：utf8mb4_unicode_ci 和 utf8mb4_general_ci 混用也可能导致无法走索引
ON 条件里套了函数：ON UPPER(u.name) = UPPER(o.name) —— 索引完全失效
统计信息过期：表数据大改后没运行 ANALYZE TABLE users;，优化器误判成本，选错执行路径

这类问题在 Navicat 里看不出端倪，必须回到命令行或用 SHOW CREATE TABLE 对比字段定义，再结合 EXPLAIN 逐项排除。

被驱动表索引到底建在哪、怎么建才管用

只在被驱动表的 ON 条件字段上建索引，而且要精准：

如果是 SELECT * FROM A JOIN B ON A.b_id = B.id，且优化器选 A 为驱动表（看 EXPLAIN 中 table 列顺序或 FORMAT=JSON 的 "leading_table"），那索引必须建在 B.id 上
单列索引最稳妥：ALTER TABLE users ADD INDEX idx_id (id);
若还有其他等值过滤条件，可建联合索引，但关联字段必须放最左：ALTER TABLE users ADD INDEX idx_status_id (status, id); —— 这样 WHERE status = 'active' AND ... JOIN ... ON ... = users.id 才能复用