navicat 不记录慢sql日志，需在mysql或postgresql服务端开启慢日志并配置合理阈值；其查询分析器和explain功能存在采样盲区与执行计划偏差，索引查看器无法验证实际生效情况；报表优化应优先重写sql而非依赖客户端工具。
navicat 里根本看不到报表慢 sql 的日志
navicat 不采集、不存储任何慢查询记录，它只是个客户端。报表跑得慢，你不会在 navicat 界面里自动弹出“这条 sql 很慢”的提示——除非你提前让 mysql 或 postgresql 服务端开了慢日志，并且手动去查。
关键动作只有两个：slow_query_log=ON（MySQL）或 log_min_duration_statement（PostgreSQL）必须先设好；日志路径得能被你本地机器访问到（远程服务器上的 /var/log/mysql/slow.log，Navicat 双击打不开，得先下载）。
- MySQL 默认
long_query_time=10，报表类查询常卡在 2~5 秒，建议临时设成0.5（SET GLOBAL long_query_time = 0.5） - PostgreSQL 中
log_min_duration_statement = 500表示记录耗时超 500ms 的语句，比默认的 -1（关闭）有用得多 - 别依赖 Navicat 的「查询分析器」抓报表慢 SQL——它轮询间隔默认 5 秒，而多数报表 SQL 耗时 3 秒就结束了，根本来不及捕获
右键“解释”只对当前语句有效，且容易误判
报表 SQL 往往带参数、子查询、多层 JOIN，直接在 Navicat 查询编辑器里粘贴后右键点「解释」，结果可能和真实执行计划不一致：
- 如果语句里有
WHERE create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY)这类动态时间计算，EXPLAIN无法预估行数，rows列可能显示极小值，但实际跑起来扫描几十万行 - 跨库查询如
SELECT * FROM report_db.summary JOIN core_db.user，Navicat 在非report_db下执行EXPLAIN，key列可能为空或possible_keys错漏 - MySQL 8.0+ 默认用
FORMAT=tree，Navicat 解析表格时会截断嵌套结构，建议手动写成EXPLAIN FORMAT=TRADITIONAL SELECT ...
索引查看器看不出字段顺序是否匹配报表 WHERE 条件
Navicat 的「设计表 → 索引」页能列出所有索引，但不会告诉你这个索引对报表 SQL 是否真正生效：
- 比如报表常查
WHERE status = 'done' AND created_at > '2024-01-01' ORDER BY updated_at DESC，你建了INDEX(status, created_at)，但没包含updated_at，Extra里照样出现Using filesort -
possible_keys有值、key为空？可能是优化器认为走索引不如全表扫描快——尤其当status = 'done'占全表 80% 行时，即使索引存在也不会用 - 函数包裹字段直接废掉索引：
WHERE DATE(created_at) = '2024-06-01'比created_at >= '2024-06-01' AND created_at 多扫几倍数据，Navicat 索引页看不出来
报表 SQL 重写比加索引更立竿见影
很多报表慢，不是因为没索引，而是逻辑本身不可扩展。Navicat 帮不上忙，但你能立刻改代码：
- 把
SELECT COUNT(*) FROM orders WHERE user_id IN (SELECT id FROM users WHERE region = 'CN')拆成两步：先查出 CN 用户 ID 列表（SELECT id FROM users WHERE region = 'CN'），再用IN (1,2,3...)——避免关联子查询触发嵌套循环 - 报表分页用
LIMIT 100000, 20？换成基于游标的分页：WHERE id > last_seen_id ORDER BY id LIMIT 20，rows从百万级降到几十行 - 临时表生成中间结果比反复 JOIN 更稳：
CREATE TEMPORARY TABLE tmp_report AS SELECT ...，再从tmp_report查，Navicat 支持执行整段含 DDL 的脚本
真正卡住的点，往往藏在动态条件拼接、未预估数据量的子查询、以及把报表当实时查询用的惯性思维里——这些 Navicat 的 UI 功能既不提示，也不阻止。
