加密字段不能直接GROUP BY，因数据库按密文字节分组而非明文；MySQL可用STORED生成列+索引，PostgreSQL宜用物化视图预解密，高频场景推荐写入时存脱敏标识字段。
加密字段不能直接 GROUP BY
数据库对 encrypted_name 这类字段执行 GROUP BY，实际是在按密文字节分组，比如 'Xz9aKmF1N2JkZmQ=' 和 'YmFyMjNiYzQ1NmQ=' 会被视为完全不同的组——哪怕它们解密后都是“张三”。更关键的是，几乎所有主流数据库（MySQL/PostgreSQL/SQL Server）都禁止在 GROUP BY 子句中调用解密函数，例如 GROUP BY AES_DECRYPT(encrypted_name, 'key') 会直接报错或拒绝执行。这不是语法限制，而是执行计划层面的硬约束：解密无法下推到索引，也无法被优化器识别为可分组表达式。
MySQL 8.0+ 推荐用 STORED 生成列 + 索引
核心思路是把解密逻辑“固化”进表结构，让数据库把它当普通字段处理。前提是密钥稳定、且能接受重建成本。
- 添加生成列必须用
STORED（VIRTUAL不支持索引）：ALTER TABLE users ADD COLUMN name_plain VARCHAR(100) GENERATED ALWAYS AS (AES_DECRYPT(encrypted_name, 'my_key')) STORED;
- 立刻建索引：
CREATE INDEX idx_name_plain ON users(name_plain);
- 后续统计就和普通字段一样：
SELECT name_plain, COUNT(*) FROM users GROUP BY name_plain;
注意：密钥硬编码在表达式里，轮换密钥时需 DROP COLUMN + 重建，且 AES_DECRYPT 返回 VARBINARY，建议显式转成 VARCHAR 并指定字符集，否则可能因隐式转换导致索引失效。
PostgreSQL 推荐物化视图预解密
PostgreSQL 的 pgcrypto.decrypt() 是 volatile 函数，无法用于生成列或表达式索引。最稳妥的路径是用物化视图提前解密并定期刷新。
- 先启用扩展：
CREATE EXTENSION IF NOT EXISTS pgcrypto;
- 创建物化视图（注意字符集转换）：
CREATE MATERIALIZED VIEW users_decrypted AS SELECT id, convert_from(decrypt(encrypted_name, 'key'::bytea, 'aes'), 'UTF8') AS name_plain FROM users;
- 统计时直接查视图：
SELECT name_plain, COUNT(*) FROM users_decrypted GROUP BY name_plain;
- 刷新命令（适合 T+1 场景）：
REFRESH MATERIALIZED VIEW users_decrypted;
若需近实时，可在写入时用触发器同步解密结果到宽表，但会增加写入延迟；不建议在查询时实时调用 decrypt() 配合 GROUP BY，全表扫描代价极高。
业务层更推荐写入时存脱敏标识字段
真正高频、低延迟的统计需求，不要依赖数据库解密。在写入加密字段的同时，额外存一个轻量级脱敏标识，比如：
-
email_domain_hash：用HASHBYTES('SHA2_256', SUBSTRING(email, CHARINDEX('@', email), LEN(email)))存邮箱域名哈希 -
phone_prefix：直接提取手机号前三位LEFT(phone, 3) -
idcard_province：身份证前两位（GB/T 2260 行政区划码）
这些字段可建普通索引，GROUP BY 毫秒级响应，且天然规避密钥管理、性能抖动、字符集乱码等所有数据库层解密问题。唯一代价是多占几字节存储——但比起每次查询都解密几百上千万行，这点空间几乎可以忽略。
