如何在SQL中对加密后的字段进行有效的分组聚合统计？

加密字段不能直接 GROUP BY，因为相同明文加密后密文不同，导致每行自成一组、统计失效；数据库GROUP BY仅做字节比较，不触发解密，且AES带随机IV等机制使密文必然差异。

直接对加密字段 GROUP BY 没有意义——相同明文加密后字节不同，分组结果全是单行，统计失效。

为什么加密字段不能直接 GROUP BY

数据库的 GROUP BY 是纯字节比较，不触发解密逻辑。AES 加密带随机 IV、填充差异或 Base64 编码不一致时，哪怕两个邮箱完全一样，密文也大概率不同。你看到的“每条记录自成一组”“COUNT 始终为 1”，就是这个原因。PostgreSQL、MySQL、SQL Server 全部如此，没有例外。

实时解密再分组：能用但极不推荐

MySQL 中可用 AES_DECRYPT() 在查询中还原，但必须同步处理三件事：

• AES_DECRYPT() 返回 VARBINARY，得用 CONVERT(... USING utf8mb4) 转成字符串，否则字符集错乱
• 解密失败返回 NULL，而 NULL 在分组里自成一组，得加 WHERE AES_DECRYPT(...) IS NOT NULL 过滤
• 每次查询都全表解密 + 类型转换，无法走索引，10 万行以上就明显卡顿

示例（仅限小数据量临时查）：

SELECT CONVERT(AES_DECRYPT(encrypted_email, 'key') USING utf8mb4) AS email_plain, COUNT(*)<br>FROM users<br>WHERE AES_DECRYPT(encrypted_email, 'key') IS NOT NULL<br>GROUP BY CONVERT(AES_DECRYPT(encrypted_email, 'key') USING utf8mb4);

真正可行的方案：写入时归一化或结构层预解密

把“解密”从查询时搬到写入时或表结构层，才能兼顾安全与性能：

• 入库时额外存一个确定性哈希字段，如 HMAC-SHA256(email, 'salt')，然后 GROUP BY email_hash——快、可索引、防碰撞
• MySQL 8.0+ 可建 STORED 生成列：ALTER TABLE users ADD COLUMN email_plain VARCHAR(255) GENERATED ALWAYS AS (CONVERT(AES_DECRYPT(encrypted_email, 'key') USING utf8mb4)) STORED;，再给该列建索引
• PostgreSQL 推荐物化视图：CREATE MATERIALIZED VIEW users_email_plain AS SELECT id, convert_from(decrypt(encrypted_email, 'key'::bytea, 'aes'), 'UTF8') AS email FROM users;，定期刷新后直接分组

生成列和物化视图都要求密钥硬编码在定义里，密钥轮换时需重建——这点常被忽略，上线前务必验证流程。

别碰 WHERE 或 GROUP BY 里的解密函数

写成 GROUP BY AES_DECRYPT(encrypted_email, 'key') 或 WHERE AES_DECRYPT(...) = 'xxx' 是最典型误用。MySQL 会报错（Invalid use of group function），PostgreSQL 直接拒绝执行（volatile 函数不可索引）。这类写法既慢又不可靠，且无法被任何优化器加速。

加密字段分组的本质矛盾在于：业务需要语义一致性，而加密保障的是字节不可预测性。绕不开的取舍是——要么放弃可逆加密改用哈希归一化，要么接受写入时多存一列脱敏标识。想靠一条 SQL 现场解密搞定，只会让查询越来越慢、越来越难维护。