navicat查询分析器因5秒轮询机制无法捕获800ms级瞬时慢查询，易误判累积耗时为单次峰值；应手动执行show full processlist（mysql）或select pid, query, now()-backend_start from pg_stat_activity where state='active' order by now()-backend_start desc limit 10（postgresql）精准定位。
查询分析器根本抓不到真正的慢查询
navicat 的「查询分析器」默认每 5 秒轮询一次 information_schema.processlist，而一个耗时 800ms 的语句大概率在两次采样之间就执行完了，压根不会出现在列表里。它更适合看“持续活跃”的长连接，而不是瞬时慢查询。
如果你看到某条语句在分析器里排第一，但实际执行却很快，大概率是它把历史累积耗时（比如同一条语句执行了 200 次，每次 500ms）当成了单次慢查询。
- 别依赖“前 5 个查询”排序结果做优化决策——它反映的是频次 × 平均耗时，不是单次峰值
- State 显示
Sending data或Copying to tmp table时，语句已进入执行中段，此时杀掉也来不及优化 - 想定位真正卡住的语句，不如手动执行：
SHOW FULL PROCESSLIST（MySQL）或SELECT pid, query, now()-backend_start FROM pg_stat_activity WHERE state='active' ORDER BY now()-backend_start DESC LIMIT 10（PostgreSQL）
右键“解释”不等于看懂执行计划
Navicat 的右键 → “解释”确实能调出 EXPLAIN 结果，但默认行为容易误导：MySQL 8.0+ 默认用 FORMAT=tree，Navicat 解析不全，关键字段如 rows、key 可能缺失或错位；跨库查询（如 SELECT * FROM db2.table）会导致 key 列为空，误判为“没走索引”。
- 务必手动加前缀：
EXPLAIN FORMAT=TRADITIONAL SELECT ...，确保字段对齐、信息完整 - 在目标数据库下执行
EXPLAIN，不要在mysql或information_schema库里试 -
type=ALL是危险信号，但type=ref+rows=500000更值得警惕——扫描行数比实际结果多两个数量级，说明索引选得不对或数据倾斜
从慢日志复制 SQL 到 Navicat 执行会报错
MySQL 慢日志开头有 # Time: 2024-05-12T09:23:41.123456 和 # User@Host: 这类注释行，直接全选粘贴进 Navicat 查询窗口执行，必然触发 ERROR 1064 (42000)。
- 打开慢日志文件后，只复制
# Query_time:后面那行开始的纯 SQL，跳过所有以#开头的行 - 如果日志里有
SET timestamp=...，也得删掉——它不是可执行语句，只是日志元信息 - 更稳妥的做法：用
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log提取 Top 10 最耗时语句，再逐条复制到 Navicat
别指望查询分析器自动告诉你怎么建索引
Navicat 的索引查看器（设计表 → 索引）只展示现有结构，不会提示“你该在 user_id, status 上建复合索引”。它只能帮你验证：执行计划里 possible_keys 有值但 key 为空，说明索引存在却没被选中——这时候得人工判断是不是最左前缀不匹配、类型隐式转换，或者统计信息过期。
- WHERE 中写
WHERE YEAR(create_time) = 2023，哪怕create_time有索引，key也一定是空的 - 复合索引
INDEX(a, b, c)能用于WHERE a=1 AND b=2，但不能用于WHERE b=2 AND c=3——索引查看器不会标红警告，得你自己对照 - 执行
ANALYZE TABLE table_name更新统计信息后，再跑一遍EXPLAIN，有时优化器就“想通了”
真正卡住的地方往往不在 Navicat 界面里，而在服务端配置是否开启、日志路径能否访问、SQL 是否被注释污染、以及你有没有意识到 rows 比 type 更能说明问题。
