navicat仅用于查看和验证慢查询，不采集存储日志，真正分析需依赖服务端日志或性能视图；需确认slow_query_log开启且路径可写、避免查mysql.slow_log表、跨库explain需结合performance_schema验证、锁等待需查innodb_trx与innodb_lock_waits。
navicat 本身不采集、不存储慢查询日志，也不能替代服务端监控；它只是帮你「看」和「验」——真正分析生产慢查询，必须依赖 mysql/postgresql 服务端的日志或性能视图，navicat 只负责连接、执行、展示和人工复核。
确认 slow_query_log 是否真开启且写入有效路径
很多人在 Navicat 里执行 SHOW VARIABLES LIKE '%slow_query_log%' 看到 ON 就以为万事大吉，但实际日志可能根本没写进去。常见原因包括：
-
slow_query_log_file路径权限不对（mysqld 进程用户如mysql无法写入） - 日志文件被 logrotate 清空后未重建，或磁盘满导致静默失败
-
long_query_time设为 0 时，MySQL 5.6+ 默认忽略管理语句（如SELECT USER()），但某些慢 SQL 仍可能漏记
实操建议：在 Navicat 中执行 SELECT @@slow_query_log_file, @@long_query_time;，然后用系统命令验证该路径是否可写：sudo -u mysql touch /var/log/mysql/mysql-slow.log（失败则需修权限或改路径）。
别查 mysql.slow_log 表，直接读文件 + 外部脚本解析
mysql.slow_log 表默认关闭，即使开启也无索引、无分区、SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10 在日志量大时会拖垮 Navicat 响应——这不是慢查询问题，是表设计问题。
实操建议：
- 确保
slow_query_log = ON且log_output = 'FILE'（不是'TABLE'） - 用外部轻量脚本（Python 或 shell）每分钟
tail -n 200 /var/log/mysql/mysql-slow.log，匹配# Query_time:行提取耗时与 SQL 片段 - Navicat 仅用于收到告警后，粘贴该 SQL 执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...查执行计划
跨库查询的 EXPLAIN 结果不可信，必须结合 performance_schema 验证
在 Navicat 中对 SELECT * FROM db1.t1 JOIN db2.t2 点「解释」，key 列常为空、rows 严重失真——因为 MySQL 的 EXPLAIN 不跨库读取统计信息，只查当前连接默认库的索引元数据。
实操建议：
- 先切换到语句中主表所在库（右键数据库 →「设为默认」），再执行
EXPLAIN - 开启
performance_schema（SELECT @@performance_schema;应返回ON），在 Navicat 查询分析器中筛选该语句 digest，看真实rows_examined和avg_timer_wait - 若用 MariaDB 17.0+，Navicat 的「可视化解释」能直接从
events_statements_summary_by_digest提取跨库语句的真实指标
锁等待场景下，SHOW PROCESSLIST 只是起点，得查 INNODB_TRX + INNODB_LOCK_WAITS
Navicat 里点表名卡住、执行 SQL 一直转圈，大概率不是慢，是锁住了。但 SHOW PROCESSLIST 只显示「谁在等」，不显示「等谁」和「等什么资源」。
实操建议：
- 先执行
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started DESC LIMIT 5;，找trx_state = 'RUNNING'且trx_started超 300 秒的线程 - 再执行
SELECT * FROM information_schema.INNODB_LOCK_WAITS;，有结果说明存在锁等待链 - 只对确认阻塞别人的线程执行
KILL <code>trx_mysql_thread_id;，避开system user或event_scheduler类型进程
真正难的从来不是看到锁，而是判断哪个线程该杀、杀完会不会丢事务——这需要结合业务上下文，Navicat 提供不了这个判断依据。
