SQL中对敏感数据做列级加密或脱敏，核心是“按需保护、最小暴露、不影响业务”，不是所有字段都要加解密逻辑，也不是越复杂越安全。
哪些字段适合列级加密
真正需要加密的，通常是明确受监管或高风险的字段：身份证号、手机号、银行卡号、住址、生物特征（如人脸哈希）、密钥材料等。这些字段一旦泄露会造成直接法律或安全后果。
- 避免对主键、外键、索引字段加密——会导致关联查询失效、性能骤降
- 避免对高频查询条件字段（如状态、类型、时间戳）加密——无法走索引，全表扫描风险高
- 邮箱可考虑部分脱敏（如 user@***.com），而非全量加密；密码必须用不可逆哈希（bcrypt/scrypt），不归入列加密范畴
列级加密的主流实现方式
实际落地时优先选数据库原生能力，其次才是应用层处理：
- MySQL 8.0+：用 AES_ENCRYPT() / AES_DECRYPT() 配合密钥管理服务（如Vault）或环境变量传入密钥，注意密钥绝不能硬编码在SQL里
- PostgreSQL：推荐 pgcrypto 扩展，用 pgp_sym_encrypt() + GPG密钥，支持密钥轮换和签名验证
- SQL Server：启用 Always Encrypted，密钥由客户端驱动管理，服务端全程看不到明文，但要求驱动和应用适配
- 应用层加密（如Java用JCE、Python用cryptography）：灵活但需统一加解密逻辑，务必确保所有写入口（API、后台任务、ETL）都调用同一套工具，否则出现“半加密脏数据”
脱敏比加密更常用，也更轻量
多数场景下，展示/日志/测试环境只需脱敏，无需加解密开销：
- 手机号：保留前3后4，中间用*代替 → 138****1234
- 身份证号：只显示出生年月+性别位+末4位 → 199001X****1234（X为性别码）
- 银行卡号：仅显示后4位 → **** **** **** 5678
- SQL中可用 SUBSTRING() + CONCAT() 实现，但建议封装为数据库函数或视图，避免每个查询重复拼接
必须同步做的几件事
光加密字段远远不够，配套措施不到位等于白做：
- 审计日志要记录谁、何时、对哪张表哪列执行了加密/解密操作（尤其DBA权限）
- 备份文件也要加密——否则攻击者拖走备份就能还原全部明文
- 开发/测试库必须用真实脱敏数据（非随机填充），否则掩盖字段长度、格式、空值等引发上线异常
- 密钥轮换要有计划：比如每季度更新一次加密密钥，并保留旧密钥用于历史数据解密，新数据用新密钥加密
