SQL注入防护不能靠数据库加密补救，真正有效的是参数化查询与权限最小化；数据库加密仅防存储泄露，对运行时注入无效。
SQL注入防护不能靠数据库加密补救
数据库加密（如TDE、列级加密）对防御SQL注入完全无效。攻击者根本不需要解密数据——只要能执行任意SQL，就能直接 SELECT 出明文字段，或用 UNION SELECT 把敏感内容带出。加密解决的是存储介质泄露（如硬盘被盗）、备份文件被窃等场景，和运行时的注入漏洞属于不同安全层级。
真正起效的只有参数化查询 + 权限最小化
SQL注入的本质是代码与数据边界混淆。唯一可靠方案是让数据库引擎从语法层面区分“语句结构”和“用户输入”：
- 所有动态拼接的查询必须使用预编译参数，例如 Python 的
cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，而非"SELECT ... WHERE id = " + str(user_id) - 数据库账号严格遵循最小权限原则：Web应用账号只赋予必要表的
SELECT/INSERT/UPDATE权限，禁用DELETE、DROP、EXECUTE及访问系统表（如information_schema）的权限 - 禁用拼接式动态SQL，尤其避免在存储过程中用
CONCAT()或EXECUTE IMMEDIATE组装用户输入
哪些“看似加固”的操作实际无效甚至有害
开发者常误用以下手段，反而掩盖问题或引入新风险：
- 对输入做
mysql_real_escape_string（PHP）或简单转义单引号——无法防御数字型注入（如id=1 OR 1=1）或宽字节注入 - 前端JavaScript校验（如正则过滤
'）——绕过浏览器即可发起请求，毫无意义 - 启用
magic_quotes_gpc（已废弃）或全局addslashes——破坏正常数据，且可被编码绕过 - 用ORM但错误调用原生SQL方法，例如 Django 的
Model.objects.extra(where=["name = '%s'" % user_input])—— 参数化失效
加密仅在特定环节有意义：敏感字段单独加解密
若业务强要求保护某些字段（如身份证号、手机号），应在应用层加密后存入数据库，而非依赖数据库自带加密：
- 使用行业标准算法（如AES-256-GCM），密钥由KMS托管，绝不硬编码在代码中
- 加密逻辑放在应用服务内，数据库只存密文；解密也只在必要业务流程中进行，避免全量解密缓存
- 注意索引失效问题：加密后字段无法直接用于
WHERE等值查询，需改用令牌化（tokenization）或盲索引（deterministic encryption）并接受安全折衷
真正的难点从来不是“怎么加”，而是密钥生命周期管理、加密上下文一致性、以及性能损耗与安全性的平衡——这些都发生在应用侧，和SQL注入无关。
