navicat本身不生成慢查询，需先确认mysql服务端slow_query_log是否开启（show variables like 'slow_query_log'），再根据log_output是file还是table选择查看日志文件或直接查询mysql.slow_log表并按query_time desc排序。
navicat 本身不生成、不聚合慢查询，它只是查看入口——真正要找到“最慢的 sql”，得靠 mysql 服务端记录的日志或表，再用 navicat 去读取和筛选。
确认 MySQL 慢查询日志是否真的在记录
很多用户在 Navicat 里查不到慢 SQL，第一反应是“工具坏了”，其实是 MySQL 根本没开日志。执行以下语句验证：
SHOW VARIABLES LIKE 'slow_query_log';
如果返回 OFF，那后续所有操作都白忙。必须先开启：
SET GLOBAL slow_query_log = ON;- 同时检查阈值：
SHOW VARIABLES LIKE 'long_query_time';，默认是 10 秒，建议临时设为1或0.5方便捕获 - 确认日志输出方式：
SHOW VARIABLES LIKE 'log_output';，值为FILE表示写入文件，TABLE表示写入mysql.slow_log表（后者更方便 Navicat 直接查）
用 Navicat 直接查 mysql.slow_log 表（推荐方式）
如果 log_output 是 TABLE，Navicat 就能像查普通表一样打开 mysql.slow_log。这是最直观的方式：
- 在对象浏览器中展开
mysql数据库 → 找到并双击slow_log表 - 默认按
start_time降序，但“最慢”要看query_time字段，右键表 → “排序” → 选query_timeDESC - 注意：该表字段含
sql_text（带换行和注释）、query_time（秒级浮点数）、lock_time、rows_sent、rows_examined - 如果表为空，不是 Navicat 问题，而是没触发慢查询（或日志写到了文件里）
从慢查询日志文件里定位最慢 SQL（log_output=FILE 时）
当日志写入文件（如 /var/lib/mysql/hostname-slow.log），Navicat 无法直接解析格式，但可以辅助查看：
- 先用命令查路径：
SHOW VARIABLES LIKE 'slow_query_log_file'; - 在服务器上用
tail -n 100 /path/to/slow.log | sort -k2 -r（按时间倒排）或手动搜# Query_time:行 - 把最可疑的几条 SQL 复制进 Navicat 查询窗口，加
EXPLAIN分析执行计划，重点看type是否为ALL、key是否为空、rows是否远超结果集 - 别依赖日志里的
Rows_examined判断“最慢”——它只反映扫描量，实际耗时还受锁、IO、网络影响
避免被“假慢”干扰：连接空闲超时导致的首查延迟
有时你发现 Navicat 执行同一条 SQL，第一次特别慢，之后飞快——这不是 SQL 本身慢，是 MySQL 断开了空闲连接，Navicat 重连后首次查询触发了连接重建和权限校验。
- 检查 Navicat 连接设置：右键数据库 → “编辑连接” → “高级” → 勾选“保持连接间隔”，填
60（单位秒） - 这个参数不能设太大（比如超过
240），否则可能撞上 MySQL 的wait_timeout，反而引发异常断连 - 这种延迟不会记入慢查询日志，
EXPLAIN也看不出问题，得结合执行时间波动和连接行为判断
真正难的不是找到“最慢”的那条 SQL，而是区分它是真性能瓶颈，还是配置、网络或客户端行为导致的假象。每次看到一条高 query_time 的记录，先确认它是否稳定复现，再用 EXPLAIN 看执行计划，最后才动索引或改写逻辑。
