Navicat打开表缓慢主因是客户端行为：默认执行SELECT COUNT(*)获取行数、心跳间隔不匹配导致连接重建、以及自动加载BLOB内容；需同步关闭“自动获取行数”、将心跳设为比wait_timeout小至少30秒、关闭“Show BLOB content”并启用Limit rows。
Navicat 连接成功后打开表极其缓慢，大概率不是数据库慢，而是客户端在后台偷偷执行 SELECT COUNT(*) 或全量拉取数据导致的——这两件事会直接卡死界面，尤其在大表或云数据库上。
为什么点开一张空表也卡住几秒？
Navicat 默认开启「自动获取行数」功能，只要右键“打开表”或双击表名，它就会立刻在后台发一条 SELECT COUNT(*) FROM table_name。哪怕表里只有 10 行，这条语句本身不慢；但若表有 500 万行且无主键/无索引，MySQL 就得全表扫描，Navicat 状态栏只显示“正在获取行数”，你根本不知道它在干啥。
- MySQL 8.0+ 中
INFORMATION_SCHEMA.TABLES.TABLE_ROWS是采样估算值，Navicat 检测到不准，就强制 fallback 到COUNT(*) - 阿里云 RDS、腾讯云 CDB 等云服务常对
COUNT(*)频次限流或直接拒绝，Navicat 会反复重试直到超时 - 该功能路径为：
工具 → 选项 → 常规 → 自动获取行数（默认勾选） - 关闭后，表上方“共 XXX 行”消失，但所有查询、编辑、导出完全不受影响
为什么第一次打开快，闲置几分钟后再开就卡住？
这是心跳间隔（Keep connection alive）和 MySQL 服务端 wait_timeout 不匹配导致的“假死”。Navicat 认为连接还活着，实际已被服务端悄悄断开，等你点开新表时才触发重建连接流程，卡在 TCP 握手 + 认证环节。
- 查服务端真实值：
SHOW VARIABLES LIKE 'wait_timeout';（云数据库常见值为 300 秒） - Navicat 默认心跳是 240 秒，比服务端小但余量不足；网络抖动或服务端 GC 延迟一发生，心跳包就迟到
- 正确做法：连接设置 → 高级 → 勾选
Keep connection alive，填比服务端值小至少 30 秒（如服务端是 300，这里填 260） - 别设成 30 以下——太频繁的心跳反而增加服务端负担，且某些云厂商会主动丢弃高频 ping
为什么表结构含 TEXT/BLOB 字段时更卡？
Navicat 默认开启「显示 BLOB 内容」，遇到 TEXT、MEDIUMTEXT、BLOB 等字段，会尝试把整段内容加载进内存并渲染预览，哪怕你只想要前 10 行数据。
- 关闭路径：
工具 → 选项 → 查询 → 取消勾选 Show BLOB content - 同时检查「高级」设置中是否启用
Limit rows（必须填具体数字，如100，不能留空） - 旧版 Navicat 在未设
Limit rows时，SELECT * FROM users LIMIT 10也会先拉全量再本地截断——跨公网查千万级表时，光传输就耗掉十几秒 - 如果真要导出全量，用右键表 → 导出向导 → 选
Server export，绕过 Navicat 中转
真正容易被忽略的是：这些设置之间存在隐式依赖。比如关了「自动获取行数」但没设 Limit rows，打开表仍可能卡在渲染阶段；设了心跳但没关 BLOB 显示，大字段依然拖垮内存。调优必须同步改这三项，缺一不可。
