点了“解释”按钮没反应，大概率是sql语句不完整或非select/update/delete类型、用户权限不足（如mysql缺process权限）、语句含多余分号或中间注释导致解析失败。
点了“解释”按钮没反应，大概率是这三件事没做对
navicat 的“解释”功能不是万能开关，它依赖语句合法性、权限和数据库能力。点下去没结果，别急着怀疑工具，先检查这几点：
- SQL 必须是完整可解析的
SELECT、UPDATE或DELETE——INSERT、SET、存储过程调用、带未绑定参数的WHERE id = ?都不支持 - MySQL 用户需有
PROCESS权限；PostgreSQL 用户需能访问pg_stat_statements（某些版本）；Oracle 需对PLAN_TABLE有写权限 - 语句末尾多了一个分号
;，或注释嵌在中间（如SELECT /* hint */ id FROM t），部分 Navicat 版本（尤其 v15.x）会直接丢弃整条语句
MySQL 里 type=ALL 和 key=NULL 真正意味着什么
这两项不是警告，是确诊书：它告诉你查询根本没走索引，正在全表扫描。
-
type=ALL表示优化器决定逐行读取整张表——哪怕只有 5000 行，也可能因随机 I/O 拖慢响应 -
key=NULL说明哪怕表上有索引，优化器也没选它。常见诱因：WHERE YEAR(create_time) = 2023（函数导致索引失效）、user_id = 123（字段是字符串，传了数字引发隐式转换） - 别只盯着
type判断快慢：右键执行计划表格 → “显示所有列”，重点看rows值——它才是预估扫描行数，type=ALL但rows=100可能比type=range却rows=50000更优
想看真实耗时和 I/O，必须绕开 Navicat 默认行为
Navicat 工具栏那个“解释”图标只发 EXPLAIN，不触发实际执行。你看到的只是估算，不是真相。
- MySQL：别点按钮，直接在编辑器里写
EXPLAIN FORMAT=JSON SELECT ...，按F5运行——JSON 结果里有execution_time和rows_examined_per_scan - PostgreSQL：必须手写
EXPLAIN (ANALYZE, BUFFERS, TIMING) SELECT ...，否则Buffers:和Execution Time:行根本不会出现 - 注意陷阱：查询窗口右下角状态栏显示的“耗时”是网络传输 + 解析时间，不是数据库真实执行耗时
为什么加了索引，EXPLAIN 还显示 type=range 而不是 ref
这不是 bug，是优化器在权衡。range 不等于差，ref 也不等于好——关键看 rows 和 filtered。
-
type=range常见于IN、BETWEEN、>等范围条件，即使用了索引，也得扫描索引片段 - 如果索引是复合索引
(a,b,c)，而查询只用WHERE a = ? AND b > ?，优化器可能选range而非ref，因为后缀字段无法精确匹配 - 真正要盯的是
filtered列：它表示该步骤过滤后剩余行数占比。若filtered=10.00，说明 90% 的扫描结果被丢弃了——这时才该考虑调整索引顺序或拆分条件
执行计划不是一锤定音的判决书，而是优化器在当前统计信息下的最优猜测。最常被忽略的，是没验证 rows 是否接近真实值，以及没对比 ANALYZE 前后的缓冲命中率变化。
