Navicat不支持自动脱敏，需手动编写SQL查询实现GDPR合规导出；必须取消Limit rows限制、验证全量结果、人工抽检脱敏效果与字段完整性。
导出前必须明确：Navicat 本身不提供自动脱敏功能
Navicat 是数据库管理工具，不是数据治理或隐私合规平台。它无法识别哪些字段属于“个人数据”（如 email、id_card_no、phone），也不会自动替换、哈希或泛化这些值。所谓“GDPR合规导出”，本质是你在导出前，**手动构造一条已脱敏的 SQL 查询**，再把结果导出——Navicat 只负责执行和写入文件。
用 SELECT + 函数构造脱敏查询再导出
这是最可控、最常用于生产环境的方式。你得自己写 SQL，把敏感字段替换成不可逆处理后的值。常见做法包括：
-
CONCAT(LEFT(name, 1), '***')→ 保留姓氏首字，其余掩码 -
MD5(email)或SHA2(email, 256)→ 哈希后可用于关联但不可还原（注意：GDPR 不禁止哈希，但若可暴力碰撞仍存风险） -
REPLACE(phone, SUBSTR(phone, 4, 8), '**** ****')→ 国内手机号常用掩码格式 -
DATE_SUB(created_at, INTERVAL FLOOR(RAND()*365) DAY)→ 对日期做随机偏移，保护精确时间点
⚠️ 注意：MySQL 的 RAND() 在导出时每行独立计算；PostgreSQL 需用 random()，且某些函数（如 pgp_sym_encrypt）需扩展支持。务必先在查询编辑器中执行验证结果是否符合预期，再导出。
导出时必须关掉 Limit rows，否则只脱敏前 N 行
Navicat 查询编辑器右下角默认勾选 Limit rows（通常为 1000）。如果你写了脱敏 SQL 但没取消该限制，导出向导即使选了 All records，也可能只导出缓存中的前若干行——因为 Navicat 实际只拉取了那部分结果集。
正确操作顺序是：
- 在
Query标签页写下完整脱敏 SQL（例如：SELECT id, CONCAT(LEFT(real_name,1),'***') AS name, MD5(email) AS email_hash FROM users WHERE updated_at >= '2026-01-01'） - 点击右下角取消勾选
Limit rows，或把数值改为0 - 点击 ▶ 执行，确认下方
Result区显示全部匹配行数（不是 “1000+”） - 右键结果区 →
Export Result，或走Export Wizard并在 Options 步骤强制选All records
导出后务必人工抽检脱敏效果与字段完整性
GDPR 要求“数据最小化”和“目的限定”，这意味着你导出的文件里不能残留未脱敏字段，也不能多导无关表/列。容易被忽略的点有：
- SQL 中用了别名（如
AS phone_masked），但导出 CSV 时列名就是这个别名——检查下游系统能否识别，或是否需重命名 - 导出为
SQL格式时，Navicat 默认生成INSERT语句，其中的值已是脱敏后结果；但若误选“结构和数据”模式，可能混入原始表的未脱敏快照 - 导出包含
JSON字段或TEXT大字段时，脱敏逻辑可能未覆盖嵌套内容（例如profile->>'$.email'），需在 SQL 中显式提取并处理 - 时间字段若仅用
NOW()替换，会丢失业务时间上下文；应优先用偏移、截断（DATE(created_at)）或分桶（FLOOR(HOUR(created_at)/6)）
真正卡住 GDPR 审计的，往往不是技术做不到，而是导出文件里某张表漏了一列、某个视图没重写、或者测试库导出时混进了真实用户 token —— 这些都得靠人工核对 SQL 和样本数据，Navicat 不会替你担责。
