Navicat 不记录慢 SQL，需依赖 MySQL 的 slow_query_log；先验证日志是否开启（SHOW VARIABLES LIKE 'slow_query_log'），再根据 log_output 类型查 mysql.slow_log 表或慢日志文件，注意区分真实慢查询与连接重建等环境干扰。
navicat 本身不记录、不生成慢 sql，它只是查看入口——真正要定位慢 sql，必须依赖 mysql 服务端的 slow_query_log，否则在 navicat 里任何操作都查不到。
确认 MySQL 慢查询日志是否真正在工作
很多用户在 Navicat 里查不到慢 SQL，第一反应是工具问题，其实是 MySQL 根本没开日志。执行这两条语句立刻验证：
-
SHOW VARIABLES LIKE 'slow_query_log';—— 返回OFF就白忙 -
SHOW VARIABLES LIKE 'long_query_time';—— 默认 10 秒，生产环境建议临时设为1或0.5
开启日志需用全局变量：SET GLOBAL slow_query_log = ON;。注意：仅当前会话生效的 SET slow_query_log = ON 是无效的。
优先查 mysql.slow_log 表（当 log_output = TABLE）
如果 SHOW VARIABLES LIKE 'log_output'; 返回 TABLE，那最省事的方式就是直接在 Navicat 中打开 mysql.slow_log 表：
- 在对象浏览器中展开
mysql数据库 → 双击slow_log表 - 右键表头 → “排序” → 选
query_time降序（不是start_time） - 重点看
sql_text（含换行和注释）、query_time（单位秒，浮点数）、rows_examined
该表默认无索引，数据量大时 ORDER BY query_time DESC 会卡顿；别用它做实时监控，只适合人工排查。
查日志文件时 Navicat 能做什么（当 log_output = FILE）
Navicat 无法直接解析慢日志文件格式，但可以辅助定位：
- 先执行
SHOW VARIABLES LIKE 'slow_query_log_file';确认路径，比如/var/log/mysql/mysql-slow.log - 把文件拖进 Navicat 查询窗口（仅限文本查看），或复制可疑 SQL 到新查询页
- 对复制过来的 SQL 立即右键 → “解释”，看
type是否为ALL、key是否为空、rows是否远超结果集 - 注意：日志里
# Query_time:后面的值才是真实耗时，别被Rows_examined带偏——锁等待、IO 延迟也会拉长耗时
别被“第一次执行特别慢”骗了
在 Navicat 中执行同一条 SQL，第一次慢、之后快，大概率不是 SQL 本身慢：
- MySQL 断开了空闲连接（
wait_timeout触发），Navicat 不知道，重连后首次查询要重建连接+权限校验 - 解决方案：在 Navicat 连接属性 → “高级” → 把“保持连接间隔（秒）”从默认 240 改成 20～30
- 这种延迟不会写入慢日志，
EXPLAIN也看不出异常，纯属网络与连接管理问题
真正难的是区分“SQL 固有性能差”和“环境干扰导致的假慢”——前者改索引或语句，后者调连接参数或服务器配置。
