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