逆向时需在“逆向数据库到模型”对话框中勾选“高级选项”，取消勾选information_schema、pg_catalog等系统schema，并在“对象选择”页用正则（如^(?!tmp_|stg_|backup_).+）过滤前缀表，同时确保账号无系统schema的USAGE权限。
逆向时如何过滤掉information_schema、pg_catalog等系统表
Navicat 16 默认会把所有可查的表都拉进来，包括 information_schema.tables、pg_catalog.pg_class 这类元数据表，它们不是业务表，进模型只会干扰阅读和后续同步。关键不是靠“事后删”，而是在逆向入口就掐断。
- 右键数据库 → “逆向数据库到模型”后，弹出的对话框里不要直接点确定，先勾选“高级选项”展开面板
- 在“包含对象”区域，取消勾选
information_schema（MySQL/PostgreSQL）、pg_catalog（PostgreSQL）、sys（SQL Server）等系统 schema 名称 - 若使用的是 PostgreSQL，额外确认目标连接用户没有
USAGE权限在pg_catalog上——权限越小，逆向结果越干净；否则即使界面没勾，底层仍可能扫到 - MySQL 用户注意：
performance_schema和mysql库也得手动剔除，尤其mysql.user这类表字段名（如plugin、authentication_string）在模型里会触发类型转换警告
用正则排除命名规律明显的临时表
有些团队习惯用前缀标记临时表，比如 tmp_、stg_、backup_，这类表 Navicat 不会自动识别，必须靠导入时的筛选逻辑拦截。
- 在“逆向数据库到模型”的对话框中，切换到“对象选择”页，点击右下角
Filter按钮 - 输入正则表达式，例如：
^(?!tmp_|stg_|backup_).+（匹配不以这些前缀开头的表名） - 注意：Navicat 16 的正则引擎不支持
\b或 Unicode 字符类，只认基础语法；写完务必点Test验证是否命中预期 - 如果正则测试失败或列表为空，说明当前连接返回的表名含 schema 前缀（如
public.order），需改成^public\.(?!tmp_|stg_).+
为什么“取消勾选视图/存储过程”不能解决临时表问题
很多人误以为关掉“包含视图”就能躲过临时对象，但这是错的——临时表是 BASE TABLE 类型，和视图无关；而且 Navicat 的“包含视图”选项只控制是否把 pg_views 或 INFORMATION_SCHEMA.VIEWS 本身作为表导入，不是过滤业务视图。
- 真正混入模型的临时表，90% 来自你授权给 Navicat 的账号能 SELECT 的任意表，哪怕它只是
CREATE TEMP TABLE tmp_log AS ...后残留的 - PostgreSQL 中，
pg_temp_*开头的临时 schema 表不会出现在pg_tables，所以不会被逆向到——但如果你手动CREATE TABLE tmp_xxx（非 temp schema），它就会进模型 - MySQL 中没有 temp schema 概念，只要表存在且有权限，
SHOW TABLES就能列出，逆向必进
导出前用模型验证快速定位残留系统表
就算做了上面两步，仍可能漏掉个别表，比如 DBA 手动建的 dba_audit_log 这种名字像业务实则为运维用的表。这时别翻列表，用内置校验更快。
- 逆向完成后，点菜单
Model → Validate Model - 在弹出窗口中勾选
Check for system tables（该选项默认关闭，需手动打开） - 它会扫描所有表名是否匹配已知系统 schema 模式，并高亮标出
pg_stat_statements、mysql.innodb_table_stats等典型条目 - 验证通过后，再执行
File → Export Model to XML，XML 中就不会含这些表——因为导出动作只作用于模型内有效实体，被 Validate 标红的表可直接右键删除
真正干净的模型，不是靠删，而是从逆向源头掐掉权限+命名+schema 三层入口；一旦让 tmp_order_merge 这种表进了 .nmf，后续团队协作时它会在 XML diff 里反复出现，但没人记得当初为什么加进去。
