Navicat对象筛选仅匹配已展开节点的显示名称，搜不到表须先手动展开目标schema；区分大小写及特殊字符，多schema场景应使用“在数据库或模式中查找”功能。
Navicat 对象筛选不等于全文检索，搜不到表先看 schema 是否已展开
在大表优化场景中，团队常需快速定位某张核心业务表（如 order_detail 或 user_behavior_log），但直接按 ctrl+f 输关键词却返回空——这不是软件故障，而是 navicat 的对象筛选机制只作用于**当前已展开的节点层级**。postgresql 或 mysql 多 schema 架构下，若目标表在 sales 或 log schema 中，而你没手动点开该 schema 节点，它压根不会进入筛选范围。
必须按顺序操作：
- 先在对象树中找到并展开目标 schema（如
log） - 再在该 schema 下按
Ctrl+F输入完整表名（区分大小写，含下划线或空格也得原样输入） - 若表名含特殊字符（如
order info），必须输入带空格的完整字符串，不能切词
否则哪怕表真实存在，筛选结果也为空。
结构比对时用「对象过滤」排除日志/临时表，别靠手动取消勾选
团队做表结构优化前常需比对测试库与生产库的差异，但大量日志表（audit_log、sync_task_history）、临时表（tmp_user_rank_202606）会干扰判断。此时应在结构同步向导的「选项 → 对象过滤」中配置排除规则，而非等比对完再逐个取消勾选——后者极易漏掉命名不规范的表（如 user_action_record），且无法复用。
正确做法是添加以下排除模式：
-
log.*（匹配所有以log.开头的完整对象名） -
%.%_history（注意点号是字面量，%_history不生效） -
tmp_%、__migrations等业务约定前缀
关键细节：同步不存在的对象 选项默认开启，若不关闭，即使表被排除，Navicat 仍可能在目标库重建它——这是最常被忽略的生效前提。
ER 图里搜不到表？确认你真在「模型」环境里
团队协作做大表索引优化时，常需在 ER 图中查看字段依赖、外键关系或反范式设计问题，但按 Ctrl+Shift+F 没反应，或搜出的表和实际连接里的不一致。根本原因是：Navicat 的 ER 搜索仅存在于「模型」上下文中，和对象树筛选完全隔离。
必须满足三个条件才启用 ER 搜索：
- 通过「文件 → 新建模型」或打开已有
.nm文件，顶部标题栏显示「模型 - xxx.nm」 - 从左侧数据库连接中把目标表拖进画布（仅拖入才建立元数据索引）
- 保存一次模型（
Ctrl+S），部分版本（如 Navicat 16.0.18）不保存则搜索索引未加载
如果只是双击数据库连进去看「查询」页或「对象」页，Ctrl+Shift+F 压根不会触发任何行为。
查执行计划前先确认统计信息是否更新，避免误判索引失效
团队讨论某条慢查是否该加索引时，常直接右键「解释 SQL」看 EXPLAIN 结果，却发现 type 是 ALL（全表扫描），就认定索引没生效。但更大概率是表统计信息过期，导致优化器误判——尤其在大表批量导入或删除后未 ANALYZE TABLE。
在 Navicat 中验证和修复：
- 右键目标大表 → 「维护 → 分析表」，强制刷新统计信息
- 再执行
EXPLAIN，对比rows预估值是否明显下降 - 若仍为全表扫描，再检查 WHERE 条件是否符合索引最左前缀，或是否存在隐式类型转换（如字段是
VARCHAR却传数字）
真正影响执行计划质量的，往往不是索引有没有，而是优化器“信不信”这个索引能减少扫描行数——而信任基础就是统计信息的时效性。
