加密字段不能直接group by，因数据库按密文字节而非明文语义分组，且主流数据库禁止在group by中调用解密函数；mysql 8.0+可用stored生成列+索引固化解密逻辑，postgresql宜用物化视图预解密，sql server推荐写入时存脱敏标识字段。
加密字段不能直接 GROUP BY，因为数据库按密文字节分组，不是按明文语义；所有主流数据库（MySQL/PostgreSQL/SQL Server）都禁止在 GROUP BY 子句中调用解密函数，这不是语法限制，而是执行计划层面的硬约束。
MySQL 8.0+ 用 STORED 生成列 + 索引
核心是把解密逻辑“固化”进表结构，让数据库当普通字段处理。前提是密钥稳定、能接受重建成本。
-
STORED是必须的：ALTER TABLE users ADD COLUMN name_plain VARCHAR(100) GENERATED ALWAYS AS (AES_DECRYPT(encrypted_name, 'my_key')) STORED; - 必须显式转字符集，否则索引可能失效：
CAST(AES_DECRYPT(encrypted_name, 'my_key') AS CHAR CHARACTER SET utf8mb4) - 建索引后才能高效分组：
CREATE INDEX idx_name_plain ON users(name_plain); - 密钥轮换时需
DROP COLUMN+ 重建，无法热更新
PostgreSQL 用物化视图预解密
pgcrypto 的 decrypt() 是 volatile 函数，不支持生成列或表达式索引，物化视图是最稳妥路径。
- 先启用扩展：
CREATE EXTENSION IF NOT EXISTS pgcrypto; - 创建视图时注意字符集转换：
convert_from(decrypt(encrypted_name, 'key'::bytea, 'aes'), 'UTF8') - 刷新命令是手动触发的：
REFRESH MATERIALIZED VIEW users_decrypted;，适合 T+1 场景 - 若需近实时，得靠触发器或逻辑复制同步到宽表，但写入延迟会上升
SQL Server 中别在 GROUP BY 里实时解密
SQL Server 不支持在 GROUP BY 中调用 DECRYPTBYKEY 或类似函数，强行写会报错或退化为全表扫描。
- 可行方案是写入时就存脱敏标识字段，比如：
phone_prefix CHAR(3)或email_domain_hash BINARY(32) - 这类字段可建索引、可
GROUP BY、无解密开销，且天然支持密钥轮换（只需重算标识） - 千万别写
GROUP BY SUBSTRING(ENCRYPTBYKEY(...), 1, 10)—— 这类表达式无法走索引，每次查询都是全表解密
脱敏后分组 ≠ 用 GROUP BY 做脱敏
GROUP BY 本身不修改数据，它只归类；想把手机号变成 138****1234 再分组，必须先在 SELECT 或视图中完成掩码，再对掩码结果 GROUP BY。
- 正确写法：
SELECT CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS masked_phone, COUNT(*) FROM users GROUP BY CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)); - 错误写法：
SELECT phone, COUNT(*) FROM users GROUP BY phone;—— 返回的是原始明文，没脱敏 - 更隐蔽的坑：用
CASE WHEN在SELECT里掩码，却在GROUP BY里仍写原始字段，结果仍是按明文分组
真正难的不是怎么写 SQL，而是决定在哪一层做解密：写入时存标识最稳，但要改业务逻辑；生成列或物化视图省事，但绑死了密钥和字符集；实时解密看着灵活，实际一跑就慢成瓶颈。选哪个，取决于你能不能接受重建表、能不能容忍 T+1 延迟、以及 DBA 是否允许开 pgcrypto 扩展。
