navicat 无法定时导出慢查询分析结果，因其不解析 mysql 慢日志；可靠方案是启用文件型 slow log，用外部脚本提取关键指标并告警，navicat 仅用于人工复核 explain。
navicat 不能定时导出慢查询分析结果——它压根不接触慢查询日志，也不具备解析能力。你看到的“慢查询”在 navicat 里只是普通 sql 执行结果，不是 mysql 服务端记录的真实 slow log。真要拿到可分析、可告警的慢查询数据，必须绕开 navicat 的 gui 层，直连 mysql 日志机制。
为什么在 Navicat 里查 mysql.slow_log 表不可靠
很多人试图用 Navicat 定时执行 SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10，这在生产环境会出问题：
-
mysql.slow_log表默认关闭，开启需SET GLOBAL log_output = 'TABLE'，但写入性能差、无索引，大日志量下查询直接拖垮 Navicat 响应 - 该表不保留原始 SQL 的完整上下文（比如参数化后的占位符、客户端 IP、线程 ID），无法做有效归因
- Navicat 查询结果无法自动提取耗时、锁等待、扫描行数等关键字段，更没法按
Query_time或Lock_time做阈值过滤 - 即使设了“自动运行”，Navicat 进程退出或用户登出后任务立即失效，毫无可观测性
真正能落地的方案：用文件日志 + 外部脚本提取 + Navicat 仅作复核
MySQL 原生的文件型慢日志才是唯一可信来源。Navicat 在这个流程里只承担一个角色：收到告警后人工打开、粘贴 SQL、点 EXPLAIN FORMAT=JSON 看执行计划。
- 先确保 MySQL 已启用文件日志：
slow_query_log = ON，slow_query_log_file = /var/log/mysql/mysql-slow.log，long_query_time = 1.0 - 外部脚本（Python/Shell）每分钟
tail -n 500读取日志，用正则匹配# Time:、# Query_time:、# Lock_time:、# Rows_examined:行，提取超时 SQL 和关键指标 - 命中阈值（如
Query_time > 2.0）后，把 SQL 片段和耗时写入临时文件，或推送到钉钉/企业微信 Webhook - Navicat 只用于后续动作：打开告警里的 SQL，右键 →
Explain Selected Text，检查type是否为ALL、key是否为NULL、rows是否远超预期
如果你非要用 Navicat 导出“分析结果”，只能手动导出 EXPLAIN 输出
这是唯一可行的“Navicat 内部导出”，但它不是定时、不是自动、不基于真实 slow log：
- 在查询窗口手动执行
EXPLAIN FORMAT=JSON SELECT ...（替换为你怀疑的慢 SQL） - 右键结果 →
导出数据→ 格式选JSON或Text→ 路径必须是本地可写目录（如C:\temp\explain_20260728.json） - 导出前务必勾选
使用文本限定符（双引号），否则 JSON 中的换行和引号会破坏结构 - 别指望用“自动运行”反复执行这个动作——它不会动态替换 SQL，也不会保存上次执行时间，纯手工活
最容易被忽略的一点：日志文件权限。MySQL 写日志用的是 mysql 用户，而你的轮询脚本若用 root 或普通用户运行，cat /var/log/mysql/mysql-slow.log 会 Permission denied；同样，Navicat 导出路径若落在 C:\Program Files\ 下，Windows UAC 会静默拦截写入。这些细节不提前验证，整个流程就卡在第一步。
