防范SQL注入的正确方法：两种方案能否抵御注入且效果相同？

方案1：无法抵御SQL注入 #

这个方案本质还是字符串拼接，只是多了一层PL/SQL变量声明的外壳。比如当studentId传入恶意值（如1; DROP TABLE student;--），拼接后的SQL会变成：

DECLARE @Id=1; DROP TABLE student;--; select Name from student where Id = @Id;

注释符号会截断后续语句，前面的DROP TABLE会被执行，依然会遭受SQL注入攻击。这种写法和原始的危险代码没有本质区别。

方案2：有效抵御SQL注入 #

这是标准的参数化查询实现，数据库驱动会将studentId作为纯值处理，不会把它解析为SQL语句的一部分。无论输入什么恶意内容，都会被当作Id字段的匹配值，不会破坏原有SQL的结构，能彻底避免SQL注入风险。

二者是否等效？ #

完全不等效。方案1只是换了一种拼接方式，没有解决根本问题；方案2才是行业通用的防注入正确姿势。

内容的提问来源于stack exchange，提问作者Jagan N