直接对加密字段GROUP BY无效，应写入时用HMAC-SHA256生成确定性哈希并建索引，分组时查哈希列；禁用AES_DECRYPT等函数及密文截取，确保安全、可索引与统计准确。
直接对加密字段 GROUP BY 没有意义——相同明文加密后密文必然不同，分组结果全是单行，统计失效。真正安全且可落地的方案是：**写入时生成确定性哈希值并单独存储，后续对哈希列分组**。
为什么不能在 GROUP BY 里用 AES_DECRYPT 或类似函数
数据库的 GROUP BY 是纯字节比较，不触发解密逻辑；而 AES_DECRYPT() 返回 VARBINARY，需显式转字符集，还可能返回 NULL（解密失败或密钥错），导致额外分组；更关键的是，该表达式无法走索引，10 万行以上查询就会明显卡顿。MySQL 甚至会报 Invalid use of group function 错误。
用 HMAC-SHA256 做确定性哈希并建索引
这是最推荐的做法：哈希不可逆、抗碰撞、固定输入必得固定输出，且支持索引加速分组。
- 入库时同步计算哈希：比如对邮箱字段
email，用HMAC-SHA256(email, 'your_salt')得到 32 字节二进制值，存入新列email_hmac - 给该列建索引：
CREATE INDEX idx_email_hmac ON users(email_hmac); - 分组时直接查哈希列：
SELECT email_hmac, COUNT(*) FROM users GROUP BY email_hmac; - 若需还原明文做展示，必须通过关联原始表或缓存映射，不能靠哈希反推
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; - 必须用
STORED（VIRTUAL不支持索引） - 立刻建索引：
CREATE INDEX idx_email_plain ON users(email_plain); - 密钥轮换时需
DROP COLUMN+ 重建，所有历史数据会重新解密计算——这点极易被忽略，上线前务必验证流程
别用 SUBSTRING、LEFT 等函数在 GROUP BY 中“取密文片段”
比如 GROUP BY SUBSTRING(encrypted_email, 1, 8) 看似能凑合分组，但本质仍是按密文字节切片，相同明文仍大概率散落在不同组里；更重要的是，这种表达式无法使用索引，每次都是全表扫描，性能随数据量线性恶化。
哈希归一化不是“妥协”，而是把安全与性能解耦的标准做法；最容易被忽略的点是：盐值（salt）和哈希算法必须全局一致，且哈希列本身要参与唯一性校验或去重逻辑——否则看似分组成功，实则漏统或误合。
