不能直接对原始敏感字段用AVG、COUNT等聚合函数做“脱敏后统计”；必须先脱敏再聚合（如用LEFT+RIGHT拼接手机号掩码后GROUP BY），或先聚合再混淆结果（如ROUND(AVG(salary),-3)取整），并统一处理NULL以保障分组一致性。
不能直接对原始敏感字段用 AVG、COUNT 等聚合函数做“脱敏后统计”——脱敏是数据变形操作，聚合是数值/分组计算，二者语义冲突。真正可行的是：先脱敏再聚合，或先聚合再用不可逆方式混淆结果。
脱敏后再聚合：适用于字段级确定性脱敏场景
比如身份证号、手机号需保留前3位和后4位（如 138****1234），但你还想统计“不同号段的用户数量”。这时脱敏必须在 GROUP BY 前完成，且脱敏逻辑要可复用、一致：
- MySQL 8.0+ 可用
REGEXP_REPLACE或自定义函数封装脱敏逻辑，避免 SQL 内联字符串拼接出错 - PostgreSQL 推荐用
LEFT()+RIGHT()+ 字符串拼接，注意NULL值会污染整个表达式，务必加COALESCE - 严禁在
WHERE或HAVING中对脱敏后字段做精确匹配（如WHERE phone_masked = '138****1234'），这等于变相还原原始值
示例（PostgreSQL）：
SELECT LEFT(phone, 3) || '****' || RIGHT(phone, 4) AS phone_masked, COUNT(*) AS user_count FROM users WHERE phone IS NOT NULL GROUP BY LEFT(phone, 3) || '****' || RIGHT(phone, 4);
聚合后再混淆：适用于需保护统计结果本身敏感性的场景
当聚合结果本身可能暴露业务细节（如某部门平均薪资精确到小数点后两位），就不能只脱敏原始字段，而要在聚合后加噪或区间化：
- 用
ROUND(AVG(salary), -3)向千位取整，比简单CAST更可控 - PostgreSQL 支持
pgcrypto扩展，可用gen_salt('bf')配合哈希做差分隐私雏形（不推荐生产，仅示意思路） - 更稳妥的做法是返回区间而非点值：用
MIN(salary)和MAX(salary)替代AVG，并限制分组最小行数（如HAVING COUNT(*) >= 5）
警惕 NULL 和空字符串引发的聚合偏差
脱敏函数（如 REPLACE、TRANSLATE）遇到 NULL 通常返回 NULL，而 COUNT(*) 会计入，COUNT(col) 会跳过——这会导致同一张表里“脱敏后统计数”和“原始行数”对不上：
- 所有脱敏字段参与聚合前，先用
COALESCE(col, '')或NULLIF(col, '')统一空值语义 - 若脱敏规则要求“空值输出
[REDACTED]”，则必须在SELECT和GROUP BY中使用完全相同的表达式，否则分组断裂 - Oracle 用户注意：
NVL和DECODE对''与NULL的处理不一致，优先用COALESCE
跨库兼容性：脱敏函数不是标准 SQL
SUBSTRING 在各数据库行为基本一致，但 REGEXP_REPLACE 的语法、标志位（如 'g' 全局替换）、甚至是否支持都不同：
- MySQL 5.7 不支持
REGEXP_REPLACE，只能用嵌套REPLACE模拟，性能差且易漏 - SQL Server 要用
STUFF+LEN实现掩码，无法用正则 - 如果应用需多库部署，建议把脱敏逻辑下沉到应用层（如 Python 的
pandas.DataFrame.mask），SQL 层只做纯聚合
真正难的不是写一行脱敏 SQL，而是保证脱敏规则在所有查询路径中一致执行——视图、物化视图、ETL 脚本、报表工具直连，任何一处绕过都会让整个脱敏策略失效。
