加密字段直接group by会失败，因密文无业务语义；应通过生成列（mysql）或物化视图（postgresql）预解密并建索引，避免实时解密导致全表扫描与性能崩溃。
加密字段直接 GROUP BY 会失败，因为密文无业务语义
数据库里存的是 AES 加密后的二进制或 Base64 字符串，比如 encrypted_name 字段值是 'Xz9aKmF1N2JkZmQ='。直接写 GROUP BY encrypted_name 分的是密文簇，不是真实姓名；而用 DECRYPT() 函数在 SELECT 中解密再分组，绝大多数数据库（MySQL、PostgreSQL）会报错或拒绝执行——因为解密函数通常不被允许出现在 GROUP BY 子句中，且无法下推到索引层。
MySQL 8.0+ 可用生成列 + 索引加速解密后分组
核心思路：把解密逻辑前置到表结构里，让数据库“认为”这是个普通字段。前提是使用支持函数索引的版本（MySQL 8.0.13+，PostgreSQL 12+）。
操作步骤：
- 添加虚拟生成列：
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;
注意：STORED 是必须的（MySQL 要求索引列必须是 STORED），且密钥必须硬编码在生成列表达式中——这意味着密钥轮换时需重建列和索引。
PostgreSQL 推荐用表达式索引 + 预计算视图
PostgreSQL 不支持在生成列中调用加密函数（pgcrypto 的 decrypt() 是 volatile 函数），但允许对表达式建索引。
实操建议：
- 先确保已启用
pgcrypto：CREATE EXTENSION IF NOT EXISTS pgcrypto; - 建表达式索引：
CREATE INDEX idx_decrypted_email ON users ((decode(encrypted_email, 'base64')::bytea #>> '{}'::jsonb));—— 这只是示意，实际需配合自定义解密函数 - 更稳妥做法：创建物化视图预解密关键字段：
CREATE MATERIALIZED VIEW users_decrypted AS SELECT id, convert_from(decrypt(encrypted_name, 'key'::bytea, 'aes'), 'UTF8') AS name_plain FROM users; - 定期刷新：
REFRESH MATERIALIZED VIEW users_decrypted;，然后对视图做GROUP BY name_plain
物化视图方案牺牲实时性换性能，适合 T+1 类统计场景；若需近实时，可结合触发器或逻辑复制同步解密结果到宽表。
千万别在 WHERE 或 GROUP BY 里实时调用解密函数
这是最常踩的坑：写成 GROUP BY AES_DECRYPT(encrypted_name, 'key') 或 WHERE AES_DECRYPT(...) = 'Alice'。
后果很直接：
- 全表扫描：无法利用任何索引，每次聚合都要解密全部行
- CPU 暴涨：AES 解密是计算密集型操作，10 万行可能吃满一个 CPU 核
- 查询超时：在 OLAP 场景下，5 秒变 5 分钟很常见
- MySQL 会报错
ERROR 3950 (HY000): Generated column cannot refer to a generated column类错误（如果误用于生成列依赖链）
真正需要低延迟解密聚合的场景，唯一靠谱路径是提前解密落库——哪怕多一张 users_analytics 宽表，也比在线解密强。
