存储过程不能自动防止SQL注入，关键在于是否安全编写；若内部拼接用户输入（如MySQL用CONCAT），仍会中招，必须使用参数化方式（如PREPARE+EXECUTE配合USING）或静态SQL。
存储过程真能防SQL注入？先看它怎么失效
不能自动防，关键在怎么写。存储过程只是把 SQL 逻辑移到数据库端执行，如果内部拼接了用户输入，照样中招。常见错误是用 CONCAT 或 + 拼接参数进查询字符串，比如在 MySQL 里写 SET @sql = CONCAT('SELECT * FROM users WHERE name = ''', in_name, ''''); —— 这和应用层字符串拼接没区别，in_name 传入 ' OR 1=1 -- 就直接穿透。
- 必须用参数化方式执行动态 SQL：MySQL 用
PREPARE+EXECUTE配合USING；SQL Server 用sp_executesql并显式声明参数 - 静态 SQL（不拼接）天然安全：直接写
WHERE username = @username，数据库会把参数当值处理，不会解析为语法 - 别信“存储过程+权限收紧=万无一失”，如果账号有
EXECUTE权限且过程本身不设防，攻击面还在
MySQL 存储过程中安全传参的写法
MySQL 对参数化支持较弱，尤其动态查询场景。核心原则：不用字符串拼接，改用占位符 + USING。
CREATE PROCEDURE search_user(IN p_name VARCHAR(50)) BEGIN SET @sql = 'SELECT id, email FROM users WHERE name = ?'; PREPARE stmt FROM @sql; EXECUTE stmt USING p_name; DEALLOCATE PREPARE stmt; END
-
?是唯一合法占位符，不能写成'?'或拼进字符串里 -
USING后只能跟变量名，不能是表达式或函数调用（如USING UPPER(p_name)会报错） - 每次
EXECUTE前必须PREPARE，但别在循环里反复PREPARE/DEALLOCATE，性能差；可考虑复用语句句柄或改用静态 SQL
SQL Server 存储过程里最常踩的坑
sp_executesql 是安全底线，但很多人只用对了一半。典型错误：把参数名硬编码进 SQL 字符串，或者漏写参数类型。
-- ❌ 错误：参数名被当成字面量，实际未绑定
EXEC sp_executesql N'SELECT * FROM orders WHERE status = @status',
N'@status VARCHAR(20)',
@status = 'shipped';
<p>-- ✅ 正确：参数名、类型、值三者严格对应
DECLARE @sql NVARCHAR(200) = N'SELECT * FROM orders WHERE status = @status';
DECLARE @params NVARCHAR(50) = N'@status VARCHAR(20)';
EXEC sp_executesql @sql, @params, @status = 'shipped';</p>-
@params字符串里类型必须精确匹配（VARCHAR不能简写为CHAR，长度最好明确） - 如果传入
NULL，要确保类型允许为空，否则可能隐式转换失败 - 不要用
EXEC(@sql)替代sp_executesql，前者完全不支持参数化
什么时候不该用存储过程防注入
不是所有场景都适合。过度依赖反而引入新风险。
- 应用逻辑复杂、需频繁修改时，存储过程发布成本高，容易绕过审查直接改代码
- 多数据库兼容需求（如同时支持 PostgreSQL 和 SQL Server），各家参数化语法差异大，维护难度陡增
- 查询条件高度动态（如前端传任意字段组合），硬塞进存储过程会导致大量冗余过程或被迫拼接，得不偿失
- 现有 ORM 已启用参数化（如 Entity Framework 的
Where(x => x.Name == name)），再包一层存储过程纯属叠床架屋
参数化是防注入的唯一可靠路径，存储过程只是载体之一。真正容易被忽略的是：过程内是否混用了拼接与参数化，以及 DBA 是否限制了动态 SQL 所需的最小权限。
