navicat for mariadb 的「可视化解释」功能通过 performance_schema 或慢日志分析真实执行行为，比手动 explain 更准确定位性能瓶颈，但需确保服务端 performance_schema=on、慢查询日志启用且版本≥17.0。
直接用 navicat for mariadb 自带的「可视化解释」功能，比手写 explain 更快定位瓶颈，但必须确认 mariadb 服务端已启用 performance_schema 且日志配置正确。
点开「可视化解释」前先检查 MariaDB 配置
Navicat 的执行计划依赖服务端返回的底层信息。如果点击后空白或报错，大概率不是 Navicat 问题，而是 MariaDB 侧没准备好：
-
performance_schema必须为ON（默认开启，但某些精简版镜像可能关闭）；查法：SHOW VARIABLES LIKE 'performance_schema'; - 慢查询日志需启用且路径可读：
slow_query_log = ON，long_query_time = 1（建议设为 1 秒便于捕获）； - 常规查询日志（
general_log）不建议长期开启，仅调试时临时打开，否则 I/O 压力大； - Navicat for MariaDB 17.0+ 版本才完整支持
performance_schema中的语句摘要（events_statements_summary_by_digest），旧版本只能看慢日志和手动EXPLAIN。
在 Navicat for MariaDB 中触发可视化执行计划
这不是一个独立工具，而是集成在查询编辑器里的功能按钮，操作路径很固定：
- 写好 SQL（例如
SELECT * FROM orders WHERE status = 'shipped' AND created_at > '2026-01-01';）； - 确保连接的是 MariaDB 实例（不是 MySQL 或 PostgreSQL），右上角连接名应显示
MariaDB； - 点击工具栏的
可视化解释按钮（图标是两个重叠的矩形框，悬停提示 “Visual Explain”）； - 首次使用会弹窗要求选择数据源：选
Performance Schema（优先）或Slow Query Log； - 生成后，左侧是树状结构的执行步骤（如
Table Scan、Index Range Scan），右侧是对应行的rows_examined、cost、key_used等关键字段。
为什么有时「可视化解释」和手动 EXPLAIN 结果不一致？
根本原因是数据来源不同，不是 Bug：
- 手动
EXPLAIN SELECT ...是对**当前语句实时估算**，走优化器预判路径，不实际执行； - Navicat 的「可视化解释」默认从
performance_schema.events_statements_summary_by_digest读取**历史聚合数据**，反映的是该语句模板过去多次执行的真实平均行为（比如WHERE id = ?被归一化后统计）； - 如果某条语句只执行过一次，或刚改完索引还没被采样到，
performance_schema里可能没记录，此时它会 fallback 到调用一次EXPLAIN并缓存结果； - 注意
digest_text字段会把字面值替换成?，所以你看到的“慢查询”可能是同一模板下某次传了低效参数（如WHERE user_id = 9999999导致索引失效），而非语句本身写得差。
真正要盯住的三个字段（比「是否用索引」更重要）
很多人只看 type 是否为 ref 或 range，但 MariaDB 8.0+ 的执行计划里，这三个字段暴露真实代价：
-
rows_examined：实际扫描行数，远大于rows_sent（返回行数）说明存在严重过滤浪费； -
avg_timer_wait（单位皮秒）：平均单次执行耗时，比total_timer_wait更能排除偶发抖动干扰； -
sort_merge_passes：若非零，说明ORDER BY或GROUP BY触发了外部排序，极可能缺覆盖索引或sort_buffer_size不足。
这些字段只在 performance_schema 源下可见，EXPLAIN 命令本身不提供。
