MySQL 中存储敏感数据（如身份证号、手机号、银行卡号、密码等）必须加密，不能明文保存。核心原则是：加密在应用层做，数据库只存密文；密钥与数据分离，避免密钥硬编码或和数据库同机部署。
密码类字段：永远用不可逆哈希 + 盐值
用户登录密码绝不能加密存储，而应使用强哈希算法（如 bcrypt、Argon2 或 PBKDF2），并为每个用户生成唯一随机盐值。MySQL 本身不推荐用
SHA2()或
MD5()等通用哈希函数处理密码——它们无盐、无迭代、易被彩虹表或 GPU 暴力破解。 应用层调用 bcrypt（如 Python 的
bcrypt.hashpw()、Java 的
BCryptPasswordEncoder）生成带盐哈希值，再存入 MySQL
VARCHAR(255)字段 验证时同样用原始密码 + 数据库存储的完整哈希值比对，无需解密 避免在 SQL 中用
SHA2(password, 256)直接插入——盐值缺失且无法控制迭代轮数
可逆敏感字段：AES 加密 + 应用层密钥管理
对于需后续解密使用的字段（如用户真实姓名、银行卡号），应在应用代码中完成 AES-256-GCM 或 AES-128-CBC 加密，再将密文（Base64 编码后）存入
TEXT或
VARCHAR字段。密钥不得写死在配置文件或代码中。 使用 KMS（如 AWS KMS、阿里云 KMS、HashiCorp Vault）动态获取加密密钥，每次加解密都调用 KMS API 若无 KMS，至少把密钥存在独立配置服务（如 Consul、etcd）或环境变量中，并限制数据库服务器访问权限 MySQL 8.0+ 提供
AES_ENCRYPT()/
AES_DECRYPT()，但密钥仍需传入 SQL，极易泄露（如被慢查询日志、审计日志、代理中间件捕获），不推荐生产使用
字段级透明加密（TDE）：适合合规场景，但有局限
MySQL 企业版支持 InnoDB 表空间级 TDE（Transparent Data Encryption），可加密 ibd 文件，防止磁盘被盗导致数据泄露。但它不解决内存、SQL 日志、备份文件、DBA 权限滥用等问题。
TDE 加密的是物理存储，对已授权连接的用户完全透明——DBA 仍可直接SELECT明文 仅保护静态数据（at-rest），不保护传输中（in-transit）或使用中（in-use）的数据 启用需修改配置
innodb_encrypt_tables=ON，并配置密钥环插件（keyring_file 或 keyring_okv）；密钥文件必须设严格权限（如 600），且不应与数据目录同盘
最小权限 + 审计 + 脱敏：配套必须跟上
加密只是纵深防御的一环。还需从访问控制和行为监控层面加固：
为不同应用分配专用数据库账号，按需授予SELECT/INSERT/UPDATE权限，禁用
FILE、
PROCESS、
GRANT OPTION等高危权限 开启 MySQL 企业版 Audit Log 或社区版的
general_log+过滤（慎用，性能影响大），重点记录含敏感表名（如
user_profile、
payment_card）的查询 开发和测试环境必须使用脱敏数据：用
REPLACE()、正则替换或专业工具（如 Delphix、DataSunrise）生成仿真但不可还原的假数据
