GROUP BY 不能用于数据脱敏，因其仅分组聚合而不修改字段值；真正脱敏需用字符串函数（如CONCAT+LEFT+RIGHT）或视图固化逻辑，再对脱敏后字段分组统计。
GROUP BY 本身不能直接用于数据脱敏，它不改变原始值，只分组聚合——想靠 GROUP BY 把手机号变成 138****1234，这条路走不通。
为什么 GROUP BY 不能当脱敏工具用
GROUP BY 的语义是“归类 + 聚合”，比如统计每个部门有多少人、平均薪资多少。它不会修改字段内容，也不会做字符串截取或替换。即使你写 SELECT name, phone FROM users GROUP BY name, phone，也只是去重（隐式依赖唯一组合），但 phone 值仍是明文原样返回，没做任何掩码处理。
常见误解场景：
- 误以为
GROUP BY phone后再 SELECT 其他字段就能“隐藏”真实号码（实际会报错或需加聚合函数） - 试图用
MIN(phone)或MAX(phone)模拟脱敏（结果是字典序最小/最大值，不是掩码，且不可控、无业务意义） - 在含敏感字段的视图里加
GROUP BY以为能规避泄露（权限没控制好，基表仍可直查）
真正能配合 GROUP BY 的脱敏场景：聚合层脱敏统计
GROUP BY 的合理用武之地，是在**已脱敏后的字段上做分组统计**，而不是用它来执行脱敏动作。例如：
- 先用
SUBSTRING+CONCAT把手机号脱敏成前3后4格式，再按脱敏后号码分组看重复率 - 对身份证前6位（地址码）做
GROUP BY，统计各地区用户分布，原始18位号不参与分组 - 用
HASHBYTES('SHA2_256', email)生成哈希值，再按哈希分组查撞库风险（注意：哈希不可逆，但若原始邮箱集合小，仍可能被彩虹表反推）
示例（安全可控的用法）：
SELECT CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS masked_phone, COUNT(*) AS user_count FROM users WHERE phone IS NOT NULL AND LEN(phone) = 11 GROUP BY CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) HAVING COUNT(*) > 1;
CASE WHEN + GROUP BY 是最常踩坑的组合
很多人写类似下面的语句，以为能“一边脱敏一边分组”：
SELECT CASE WHEN LEN(phone) = 11 THEN LEFT(phone,3)+'****'+RIGHT(phone,4) END AS p, COUNT(*) FROM users GROUP BY phone; -- ❌ 错！GROUP BY 还是原始 phone
这会导致语法错误（SQL Server 要求 SELECT 中非聚合列必须出现在 GROUP BY 中），或被迫改成：
GROUP BY CASE WHEN LEN(phone) = 11 THEN LEFT(phone,3)+'****'+RIGHT(phone,4) END;
但问题来了：
- 空值、格式异常的
phone会被分到同一组（CASE返回 NULL），掩盖数据质量问题 - 每次查询都实时计算脱敏逻辑，无索引支持，大数据量下性能差
- 如果后续要 JOIN 或导出，脱敏逻辑散落在多处，维护成本高
替代方案：优先用视图 + 权限控制，而非 GROUP BY
真正落地时，应把脱敏逻辑从查询中剥离，固化到数据库对象里：
- 建视图
v_users_masked，里面用CASE WHEN+SUBSTRING统一处理手机号、身份证等字段 -
立刻收回用户对基表
users的SELECT权限，只授予视图权限 —— 这步漏掉，所有脱敏都白做 - 如需分组统计，直接查视图：
SELECT masked_phone, COUNT(*) FROM v_users_masked GROUP BY masked_phone - SQL Server 2016+ 可启用
DYNAMIC DATA MASKING，但注意：它只是查询层掩码，DBA 或高权限用户仍可见原文，不适合跨环境迁移脱敏
复杂点在于：JSON 字段、嵌套结构、多级脱敏规则（如不同角色看到不同精度）无法靠简单 CASE 覆盖，得结合自定义函数或 ETL 阶段处理。
