Navicat Cloud 无法诊断慢 SQL，因其仅同步客户端元数据（如查询历史、连接配置），不采集数据库服务端的慢日志、执行计划或运行时状态；真正分析必须直连数据库执行 SHOW FULL PROCESSLIST、EXPLAIN 或查询 performance_schema。
Navicat Cloud 本身不参与慢 SQL 的实际诊断或执行分析，它只同步元数据（如查询历史、连接配置、BI 看板），无法替代 slow log 分析、EXPLAIN 执行计划查看或数据库服务端的性能采集。线上复杂慢 SQL 的协同排查，必须把 Cloud 当作“信息分发通道”，而非“分析引擎”。
为什么不能直接在 Navicat Cloud 里看慢 SQL 原因？
Cloud 同步的是你本地客户端的操作记录，不是数据库服务端的真实慢日志。当你在协作界面点开一张表卡住 5 秒，那只是本地 Navicat 重连 MySQL 导致的延迟；而真正变慢的 SELECT * FROM orders WHERE created_at > '2026-08-01' 是否命中索引、是否被锁、是否扫描了千万行——这些信息 Cloud 完全不感知，也不会转发给其他成员。
常见误操作包括：
- 以为“共享了查询语句”就等于“共享了执行上下文”，其实别人执行时用的是自己连接的库、自己的参数、自己的缓存状态
- 在 Cloud 里看到某条 SQL 被多人收藏，就默认它“已被验证过性能”，但没人知道对方当时连的是测试库还是生产库
- 协作模式下修改了对象结构（比如加了索引），却没同步更新 SQL 模板里的 hint 或 force index，导致他人复用后反而更慢
怎样让 Navicat Cloud 真正帮上慢 SQL 协同排查？
关键在于把 Cloud 当作“线索归集器”和“动作触发器”，而不是“诊断台”。实操建议如下：
- 在 SQL 编辑器中写完一条待分析的慢 SQL 后，用
/* @tag:slow-order-list-v2 */这类注释打标（Navicat 支持带标签的查询收藏），再保存到 Cloud ——这样团队能按标签快速筛选同类问题 SQL - 把
EXPLAIN FORMAT=JSON的完整输出结果，连同执行耗时、扫描行数、是否 Using filesort 等关键字段，粘贴为查询的“备注”，而不是只存 SQL 本身 - 对已确认修复的 SQL，用 Navicat 的“SQL 任务”功能建一个定时巡检任务（例如每小时跑一次
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE TIME > 60），把任务也同步到 Cloud，确保所有人能看到当前监控状态 - 禁用 Cloud 自动同步“临时查询”（设置 → 高级 → 取消勾选 “Sync temporary queries”），避免把调试中途的错误语句污染协作空间
哪些操作必须绕开 Cloud，直连数据库做？
所有需要访问服务端运行时状态的动作，都得跳过 Cloud 层，用 Navicat 本地连接直连目标实例。典型场景包括：
- 查看
slow_log表（MySQL 8.0+）或解析/var/log/mysql/mysql-slow.log文件，Cloud 不同步日志内容 - 执行
SHOW PROFILE FOR QUERY N查 CPU/IO 分布，该命令只对当前会话有效，Cloud 无法跨会话传递 profile 上下文 - 用
SELECT * FROM performance_schema.events_statements_history_long抓取最近的高耗时语句，这类表数据默认不对外暴露给 Cloud - 修改
long_query_time或打开log_queries_not_using_indexes，这些是服务端配置，Cloud 不具备写权限
最容易被忽略的一点：Navicat Cloud 上显示的“最后执行时间”，是语句在你本地执行的时间戳，不是它在数据库服务端真正跑完的时间。如果网络抖动或客户端卡顿，这个时间可能比真实执行晚好几秒——拿它去判断“是不是刚变慢”，会得出错误结论。
