加密字段不能直接 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 现场解密搞定，只会让查询越来越慢、越来越难维护。
