Navicat执行EXPLAIN FORMAT=JSON无结果，主因是缺少PROCESS权限或连接协议不兼容；应先查版本与权限，调大Max packet size，复制JSON后用JSON_PRETTY美化查看，并关注cost_info拆分、key_length及attached_condition等深层字段。
Navicat里执行EXPLAIN FORMAT=JSON没返回结果？检查连接和权限
Navicat 默认用的是普通查询模式，不自动解析 EXPLAIN FORMAT=JSON 的嵌套结构，更不会高亮或展开 JSON 字段。你直接粘贴执行后看到空结果、报错或只返回一行 NULL，大概率是 MySQL 用户缺少 PROCESS 权限（MySQL 8.0+ 对 EXPLAIN FORMAT=JSON 要求更高），或者 Navicat 连接使用了旧协议（如 MySQL 5.7 以下驱动连 8.0+ 服务端时可能截断大 JSON）。
实操建议：
- 先在 Navicat 查询窗口中单独执行
SELECT @@version;和SHOW GRANTS;，确认版本 ≥ 5.6 且含PROCESS权限 - 若用的是 Navicat Premium 16+，右键连接 → “连接属性” → “高级” → 勾选
Use SSL或调高Max packet size（设为1048576）可避免 JSON 截断 - 权限不足时，让 DBA 执行：
GRANT PROCESS ON *.* TO 'your_user'@'%'; FLUSH PRIVILEGES;
怎么让 JSON 执行计划真正“可读”？别只靠 Navicat 默认结果格
Navicat 把 EXPLAIN FORMAT=JSON 当成单字段文本返回，原始 JSON 是扁平的长字符串，没缩进、无折叠、难定位 cost_info 或 used_columns。直接复制到在线 JSON 格式化工具里看，效率低还容易漏关键路径。
实操建议：
- 在 Navicat 查询窗口中，把语句写成：
SELECT JSON_PRETTY( (SELECT * FROM JSON_TABLE(EXPLAIN FORMAT=JSON SELECT ... ) AS t) )—— 不推荐，太重；更简单的是用子查询包装：SELECT JSON_PRETTY(@json) FROM (SELECT @json := (SELECT * FROM information_schema.PROCESSLIST WHERE ID = CONNECTION_ID()) ) _—— 这也不对；正确做法是：执行完EXPLAIN FORMAT=JSON SELECT ...后，右键结果集 → “复制所选内容” → 粘贴到 VS Code 或 Sublime，装 JSON Tools 插件一键美化 - 高频分析时，建个快捷 SQL 片段：
SELECT JSON_PRETTY(@json) FROM (SELECT @json := (SELECT * FROM JSON_EXTRACT((SELECT * FROM (EXPLAIN FORMAT=JSON SELECT /* your query */ ) AS x), '$')) AS j) AS y;—— 实际不可行；真实可用的是：执行EXPLAIN FORMAT=JSON SELECT ...后，在结果面板双击 JSON 字段 → 弹出编辑框 → Ctrl+A 全选 → Ctrl+C → 打开新查询窗口 → 输入SELECT JSON_PRETTY(?)，粘贴刚才内容到问号位置，执行 - 注意：MySQL 8.0.16+ 支持
EXPLAIN ANALYZE FORMAT=JSON，它带实际执行耗时，但 Navicat 可能因超时中断——需在“工具 → 选项 → SQL 编辑器”里把Query timeout改成0（不限时）
cost_info 里的 query_cost 真的能比大小吗？
不能直接比。这个数值是优化器估算的 I/O + CPU 加权成本，单位非秒、非毫秒，不同查询间仅具相对参考性。比如两个 query_cost 分别是 120 和 180，不代表后者慢 1.5 倍；如果其中一个是全表扫描加临时表排序，另一个是走覆盖索引的范围查询，那 120 的实际耗时反而可能更高。
实操建议：
- 重点看
cost_info下的read_cost和eval_cost拆分：若read_cost占比 > 90%，说明 I/O 是瓶颈，优先考虑加索引或减少扫描行数；若eval_cost突出，可能是函数计算、类型转换或大量WHERE表达式导致 - 对比前先确保
EXPLAIN的filtered值接近真实值：执行ANALYZE TABLE your_table;更新统计信息，否则query_cost估算会严重失真 - Navicat 里看不到
used_columns和used_indexes？那是 JSON 层级太深——必须手动展开query_block → table → access_type路径，找key和possible_keys字段，别只盯最外层
为什么改了索引，EXPLAIN FORMAT=JSON 里 key 没变？
常见于复合索引顺序错、查询条件没覆盖最左前缀、或优化器认为走索引比全表扫描还贵（比如 WHERE status IN ('a','b','c') 匹配率太高）。Navicat 不提示这些隐含逻辑，只显示最终选择。
实操建议：
- 查
key_length：如果值是 0 或远小于索引定义长度，说明没用上对应字段；比如索引是(a,b,c)，但key_length只有 4，那很可能只用了a字段 - 看
attached_condition：如果这里出现cast(`t`.`c` as double)，说明类型不匹配强制转换，索引失效——得改字段类型或显式转成一致类型 - 强制走索引测试：
EXPLAIN FORMAT=JSON SELECT /*+ USE_INDEX(t idx_a_b_c) */ * FROM t WHERE ...（MySQL 8.0.19+），再对比 JSON 中key和query_cost变化
真正卡住的往往是 materialized_from_subquery 或 using_temporary_table 这类标记，它们藏在 JSON 深层，Navicat 默认不展开，需要逐层点开 query_block → nested_loop → table 才能看到——别跳过这一步。
