存储过程本身不防SQL注入，安全取决于是否拼接用户输入；用CONCAT等拼接参数等于开门揖盗，PREPARE/EXECUTE或sp_executesql若未用参数化（如USING或@params）仍危险；静态SQL指结构固定、值全由参数占位，动态拼接即高危。
存储过程本身不防SQL注入，安全与否完全取决于你有没有在内部拼接用户输入。
MySQL里用CONCAT拼接参数等于开门揖盗
很多开发者以为把查询搬到数据库里就万事大吉，结果写出这样的代码：
SET @sql = CONCAT('SELECT * FROM users WHERE name = ''', in_name, '''');只要in_name传入' OR 1=1 --，整条语句就变成SELECT * FROM users WHERE name = '' OR 1=1 --'，直接绕过认证。这种写法和PHP里"SELECT * FROM users WHERE name = '$name'"没本质区别。
- CONCAT、+、|| 这些字符串拼接操作是高危信号
- 哪怕只拼接一个字段名或表名，也足以触发注入
- MySQL的
PREPARE/EXECUTE本身不危险，危险的是不用USING传参
SQL Server中sp_executesql才是安全底线
sp_executesql支持参数化执行，但必须显式声明参数并用@param占位——否则和EXEC(@sql)一样脆弱。
错误示范：EXEC('SELECT * FROM ' + @table_name)；正确写法必须是：
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM ' + QUOTENAME(@table_name) + ' WHERE id = @id'; EXEC sp_executesql @sql, N'@id INT', @id = @id;
-
QUOTENAME()只用于动态对象名（如表名、列名），不能代替参数化处理值 - 所有用户可控的值（如
@id）必须走sp_executesql的参数列表，不能拼进@sql字符串 - 如果漏掉
N'@id INT'这个类型声明，SQL Server可能做隐式转换，埋下隐患
静态SQL天然免疫，但别误判“静态”的边界
像SELECT * FROM users WHERE username = @username这种写法，数据库引擎在解析阶段就把@username当纯数据处理，根本不会进入语法分析流程——这才是真正安全的“静态SQL”。
- 所谓“静态”，是指SQL结构固定、无运行时拼接，哪怕WHERE条件多变，只要用参数占位就仍属静态
- 一旦出现
IF @mode = 'all' SELECT * FROM t ELSE SELECT id,name FROM t，仍是静态，没问题 - 但若写成
SET @sql = 'SELECT ' + @fields + ' FROM t'，哪怕@fields来自白名单校验，也已脱离静态范畴，风险陡增
最常被忽略的一点：存储过程的安全性完全不依赖调用方，而取决于过程体内的每一行SQL。哪怕应用层用了ORM、参数化查询，只要存储过程里有一处EXEC(@unsafe)，整个防护链就断了。
