SQL层脱敏必须在查询阶段完成，优先用兼容函数如SUBSTR而非RIGHT，导出禁用--skip-extended-insert，CSV需转义特殊字符并加引号包裹，跨库需适配语法如PostgreSQL用overlay+COALESCE。
导出前用 SQL 函数直接脱敏，别等导出完再处理
数据脱敏这件事，最稳妥的时机是在查询阶段就一步到位，而不是等到数据导出后，再用脚本去二次加工。为什么？因为后处理的空窗期里，敏感字段可能已经短暂落盘、在日志里留下痕迹，甚至被中间工具缓存。相比之下，SQL层脱敏不仅最安全，整个逻辑也一目了然，审计起来非常方便。
不过，这里有个细节很容易被忽略。比如，想把手机号处理成“***1234”，很多人会顺手写成 CONCAT('***', RIGHT(phone, 4))。这个写法在MySQL 5.7及以上版本没问题，但在更早的版本里就可能报错，因为RIGHT函数对非字符串类型支持不好。更通用的做法是用SUBSTR(phone, -4)，它不仅兼容性更好，对NULL字段的处理也更合理——直接返回NULL，不会给你拼出一个“***”加空值的奇怪结果。
- 手机号：用
CONCAT('***', SUBSTR(phone, -4))。这比正则替换更轻量，而且在MySQL、PostgreSQL、Oracle里都能跑通。 - 身份证号：用
CONCAT(LEFT(id_card, 3), '****', RIGHT(id_card, 4))。注意，如果你用的是SQLite，得把LEFT/RIGHT换成SUBSTR(id_card, 1, 3)和SUBSTR(id_card, -4)。 - 邮箱：用
CONCAT(LEFT(email, 1), '****@', SUBSTR(email, INSTR(email, '@') + 1))。这样可以避免把类似test+dev@xxx.com这种带加号的邮箱，简单替换成“****@xxx.com”导致格式错乱。
导出命令里禁用 --skip-extended-insert，否则脱敏逻辑失效
接下来是导出环节的一个大坑。很多人用mysqldump时，喜欢加上--skip-extended-insert选项，觉得这样生成的INSERT语句每条一行，看起来更清晰。但问题就出在这里：这个选项会让每条INSERT语句独立执行，而你写在SELECT里的脱敏函数（比如MD5(name)）只会被计算一次，结果就是——只有第一条数据被真正脱敏，后面的N条数据全都插入了相同的值。
那正确的做法是什么？答案是绕开mysqldump的INSERT生成逻辑。直接用SELECT ... INTO OUTFILE，或者通过管道用mysql -e命令直出CSV文件。
- 安全导出示例：
mysql -u user -p -e "SELECT id, CONCAT('***', SUBSTR(mobile, -4)) AS mobile FROM users WHERE created_at > '2024-01-01'" db_name > users_anonymized.csv - 如果非用
mysqldump不可：那就别在SELECT里混用函数了。更干净的办法是，先创建一个脱敏视图（CREATE VIEW v_users_anonymized AS SELECT ..., CONCAT(...) AS mobile FROM users），然后直接dump这个视图。 - 顺便提一句，用
INTO OUTFILE需要数据库账号有FILE权限，而且输出的文件路径必须是MySQL服务端本地的路径，不能是客户端机器的路径（比如/home/user/）。
导出到 CSV 时字段含逗号、换行符，会导致脱敏后数据错列
脱敏函数只管内容替换，可不管格式兼容。举个例子，你把一个地址字段脱敏成了'北京市***区***街道\n123号'，里面既有换行符又有逗号。如果直接导出成CSV，下游用Excel一打开，行列结构肯定全乱套——到这一步再想补救，可就难了。
所以，格式问题必须在SQL层一并解决。对于MySQL，可以用REPLACE(REPLACE(addr, '\n', '\\n'), ',', '，')，把换行符转义，并把英文逗号替换成中文逗号以防字段被错误分割。PostgreSQL的写法也类似：REPLACE(REPLACE(addr, E'\n', '\\n'), ',', '，')。
- CSV导出务必加包裹符：MySQL的
FIELDS ENCLOSED BY '"'是必须项。否则，像"张三","138****1234","北京市***区"这样的数据，字段内部的引号没被转义，解析器立马就崩溃了。 - 千万别指望“Excel能自动识别”，它的猜测算法并不靠谱，一旦猜错，整个文件就废了。无论是用
LOAD DATA INFILE还是Python的csv模块读取，没有包裹符再加上特殊字符，数据丢失几乎是必然的。 - 有个简单的测试方法：导出后，用
wc -l命令数一下文件行数，看看是否等于SELECT COUNT(*)查出来的记录数。如果对不上，那基本就是格式被污染了。
PostgreSQL 的 pg_dump 不支持 SELECT 脱敏，得切到 psql \copy
如果你用的是PostgreSQL，情况又有点不同。标准的pg_dump工具只能导出整表结构或全量数据，没法让你嵌入自定义的SELECT脱敏语句。想实现这个功能，你得放弃pg_dump，切换到psql命令行工具，使用它的\copy命令。这是唯一能执行带函数的SELECT查询并直接输出到文件的方法。
这里最容易踩的坑是路径权限。\copy（带反斜杠）是一个客户端命令，路径是你本地机器的路径。而SQL命令COPY（不带反斜杠）是服务端命令，路径是数据库服务器上的路径，并且通常需要超级用户权限，普通账号基本用不了。
- 正确写法：
psql -U user -d db_name -c "COPY (SELECT id, overlay(phone PLACING '****' FROM 4 FOR 4) AS phone FROM users) TO '/tmp/users.csv' WITH CSV HEADER" - 在PostgreSQL里，
overlay函数比用substring加concat更精准，即使字段长度很短（比如空字符串）也不会报错。 - 如果字段可能为
NULL，一定要记得加上COALESCE处理，比如COALESCE(overlay(phone PLACING '****' FROM 4 FOR 4), phone)，这样可以避免因为NULL值导致整行数据被跳过。
说到底，数据脱敏远不是加几个星号那么简单。真正的挑战在于三个方面：SQL函数的跨数据库兼容性、导出命令对数据流的隐式修改、以及字段内容本身对导出格式协议的破坏。这三个环节如果不在事前对齐，最后导出来的文件，看起来是脱敏了，但数据的完整性和一致性可能早已不复存在。
