Navicat中排除敏感字段需在「字段映射」页取消勾选对应字段,确保INSERT/UPDATE语句的列名列表和VALUES值列表同步移除该字段;若字段必须参与同步,则改用数据库原生函数(如MySQL的CONCAT、PostgreSQL的REGEXP_REPLACE)在表达式中脱敏,并通过「预览」验证最终SQL生效。
navicat 不提供全局“敏感字段黑名单”,但能在同步流程中逐表控制字段级同步。关键操作在「字段映射」页——它决定 insert/update 语句里实际出现哪些列和值,而非事后删改 sql。
右键目标表 →「数据同步」→ 选择源与目标库 → 进入「字段映射」页签 → 找到敏感字段(如 password、id_card、email)→ 取消其左侧复选框。
INSERT INTO t (col1, col2) 的列名列表,也不出现在对应 VALUES() 中,彻底规避泄露风险当字段必须参与同步(如用于关联或业务逻辑),但值本身需掩码,就得靠数据库原生函数在查询层做转换。Navicat 只负责执行你写的 SQL,不干预内容。
在同步设置中,点击敏感字段右侧的「…」→ 选择「使用表达式」→ 输入脱敏语句:
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
REGEXP_REPLACE(email, '^(.+)@', '[REDACTED]@')
NULL 或 '[REDACTED]'
注意:表达式结果类型需与目标字段兼容(如把字符串塞进 INT 列会报错),且不会改变源库原始数据。
很多人以为取消勾选就万事大吉,结果同步后发现敏感字段仍被写入——根本原因是没验证最终生成的语句。必须点「预览」看真实 SQL。
INSERT INTO t (...) 是否缺失敏感字段名VALUES 中对应位置是函数调用,而非原始列名UPDATE 语句:即使 INSERT 没带 password,UPDATE 仍可能包含 SET password = ?,需同样处理password 字样,说明映射没生效或字段被其他规则覆盖有人为跳过敏感字段,临时建视图或导出 SQL 后手动删字段——这两条路都不可靠。
VALUES ('a','b') 对不上 (id, name, email)
最易被忽略的是 UPDATE 场景下的字段残留——同步向导里容易只盯 INSERT,却忘了 UPDATE 语句同样受字段映射控制,且默认行为更隐蔽。