数据库加密不能缓解sql注入漏洞本身，仅能降低拖库后的数据泄露危害；攻击者仍可执行任意sql获取密文，但无密钥无法解密身份证号、手机号等敏感字段。
它不能缓解SQL注入本身，但能大幅降低注入成功后的数据泄露危害。
SQL注入和加密是两个独立层面的问题
SQL注入是输入验证与查询构造缺陷导致的执行逻辑被篡改；AES加密是对静态数据做机密性保护。攻击者即使通过 UNION SELECT 或报错注入把整张表拖出来，拿到的也只是密文——没有密钥，就解不出身份证号、手机号这些原始值。
- 注入漏洞还在，该绕过认证还是能绕过，该删库照样能删库
- 但「拖库即失守」的连锁反应被切断了：密文无法直接用于诈骗、撞库或社工
- 你查
SELECT encrypted_id_card FROM users WHERE id = 123返回的是乱码，不是真实号码
为什么非得用AES-256-GCM，而不是AES_ENCRYPT()裸调用？
MySQL 的 AES_ENCRYPT() 在 5.7 默认用 ECB 模式，相同明文永远生成相同密文，等于给攻击者发字典。8.0+ 虽支持 GCM，但必须显式传入 iv 和 aad，且应用层要自行校验 auth_tag —— 否则攻击者可篡改密文触发填充预言攻击。
- ECB 模式下，两个用户填同一个手机号，数据库里密文一模一样，直接暴露重复性
-
AES_ENCRYPT(data, key)不带 IV 参数时，MySQL 内部可能复用固定 IV，等同于 ECB - GCM 模式要求每次加密用新随机
iv，并存下来；解密时必须原样传回，缺一不可
加密后还能按手机号查询吗？
不能直接 WHERE encrypted_phone = ?，因为每次加密结果不同。真要支持查询，得额外设计辅助机制，比如：
- 对手机号算
HMAC-SHA256(phone, salt_from_kms)存进phone_hash字段，建索引；查的时候同样哈希再比对 - 用确定性加密（如 AES-SIV），但会泄露「哪些记录的手机号相同」，隐私有折损
- 完全不想泄露任何模式？目前没成熟方案支持高并发场景下的可搜索加密（Searchable Encryption）
最常被忽略的一点：密钥保管比算法选择更关键。哪怕用了 AES-256-GCM，密钥硬编码在代码里、存在数据库同一实例中、或用环境变量明文暴露，都等于锁了门却把钥匙焊在门把手上。
