django-pgcrypto-fields加密邮箱字段查询登录耗时过长如何优化

普通索引对当前加密字段完全无效。django-pgcrypto-fields 2.5.2 默认采用带随机IV的非确定性加密，同一明文每次生成的密文完全不同，查询时必须全表扫描、逐行解密所有记录的email字段再和传入值做比对，1万条记录逐行做解密运算耗时7-8秒属于正常现象。
用username查询耗时<1s是因为username是明文存储，可直接命中普通B树索引，不需要逐行运算。

按改造成本从低到高、性能从高到低排序：

• 方案1：新增哈希辅助列查询（性能最优，推荐优先使用）
  不需要改动现有email加密字段的存储逻辑，新增辅助列做索引过滤即可：
  1. 给User模型新增固定长度的email_hash字段，类型为CharField(max_length=64)，配置db_index=True，用于存储明文email加盐后的SHA256哈希值
  2. 重写User模型的save方法，每次实例保存时，读取明文email、拼接配置文件中存储的全局固定盐值，计算SHA256哈希后写入email_hash字段
  3. 所有按email查询的逻辑（包括authenticate认证逻辑），不再直接filter(email=传入邮箱)，而是先计算传入邮箱的加盐哈希值，用filter(email_hash=计算出的哈希值)拿到候选记录，再解密候选记录的真实email字段做二次校验（避免极低概率的哈希碰撞）
     该方案下查询会直接命中哈希列的B树索引，最多解密1-2条记录，1万用户量级下查询耗时可稳定在100ms以内。
• 方案2：切换为确定性加密+表达式索引
  如果不想新增辅助列，可以调整email字段的加密配置：
  1. 将email字段的加密模式改为确定性加密（同明文同密钥下生成固定密文），在字段参数中配置deterministic=True，注意该模式下要关闭随机IV配置
  2. 给加密列创建支持解密比较的表达式索引，参考SQL：

  CREATE INDEX idx_user_email_encrypt ON app_user (pgp_sym_decrypt(email::bytea, '你配置的全局加密密钥'::text));
  

  该方案不需要大幅改动现有ORM查询逻辑，但索引体积比哈希索引大30%以上，查询性能略低于哈希辅助列方案。
• 方案3：基础性能调优
  1万条数据逐行解密耗时7-8秒本身也存在可优化的性能损耗点，可同步调整：
  • 确认加密字段使用的是对称加密算法，非对称加密解密性能比对称加密慢10倍以上，存储邮箱类字段无需使用非对称加密
  • 加密解密是纯CPU密集运算，检查数据库实例CPU配额，低性能单核CPU跑1万次对称解密确实可能达到数秒级耗时
  • 查询加密字段时用only('email', 'password')限定返回字段，避免不必要的字段解密运算放大开销

非确定性加密的密文列加普通B树索引完全不会生效，只会额外占用存储空间。
存储email哈希时必须加全局固定盐，禁止直接存明文哈希，避免拖库后被彩虹表反推用户真实邮箱。
确定性加密的安全性略低于随机IV的非确定性加密，对于邮箱这类中等敏感度字段属于可接受的安全权衡，配合哈希二次校验可进一步降低风险。

内容的提问来源于stack exchange，提问作者Leon Talukdar