禁止在代码中进行SQL的拼接操作

1. 字符串操作更容易出错。

2. sql语句不可避免地出现在代码里,无法坐到代码与数据分离.代码可读性降低。

3. 效率. 很多情况下需要多次执行同一句sql语句,只是参数不同.如果使用PreparedStatement(Java)，只需要在第一次执行是编译sql语句，之后的执行效率可以提高。

4. 如果代码里使用字符串操作来拼接sql语句,那么在编译阶段是不可能发现sql语句错误的.如果使用类库提供的方法来设置参数,可以在编译时就设定参数的类型.

5. 倘若之后要修改sql语句,比如where条件里要多加一个条件,或者为了优化性能要更改一下筛选条件的顺序,这个时候就会发现用字符串拼接是一个灾难,特别是在sql语句比较复杂的时候(有嵌套,多个表相交等).

6. 安全性.字符串拼接sql语句容易遭受sql注入攻击.

     

SQL注入是目前比较常见的针对数据库的一种攻击方式。在这种攻击方式中，攻击者会将一些恶意代码插入到字符串中。然后会通过各种手段将该字符串传递到SQLServer数据库的实例中进行分析和执行。只要这个恶意代码符合SQL语句的规则，则在代码编译与执行的时候，就不会被系统所发现。由此可见SQL注入式攻击的危害是很大的。

防止SQL注入：

　总体来说，防治SQL注入式攻击可以采用两种方法，一是加强对用户输入内容的检查与验证；二是强迫使用参数化语句来传递用户输入的内容。

比如说以前采用：

insert into test values('"+id+"','"+name+"');

现在可以改成：

           string cmd = "insert into test values(@id,@name)";
            MySqlParameter[] paras ={undefined
                                       new MySqlParameter("@id",MySqlDbType.String),
                                       new MySqlParameter("@name",MySqlDbType.String)
                                   };
            paras[0].Value = ID;

            paras[1].Value = Name;

带参数的sql语句唯一的缺点就是占用系统资源的问题了，因为它是早被预编译好的东西，所以系统在调用的时候是直接使用的。

但是相比于直接拼接的SQL语句。利还是大于弊。

7. 以后可以重构？ 为什么不现在就改，越早改动代价越小。

=================

简单点说就是把代码中，把这种+++++去掉,很不规范也不安全，换成SqlParameter

 

=================

sql 注入问题是上个世纪流行的漏洞了，

现在开发新系统还有 sql 注入漏洞的话，会被同行耻笑的 粗看了下，变量都是数值类型，应该不存在注入问题 还是用 sqlparameter 吧，正规点，不用考虑注入问题，彻底解决。

另外，不知道 sqlserver 怎么样，在 oracle 里，涉及到性能问题。如果用参数化的 sql，每次传给数据库的sql如果已经被编译过，则下次不会重新编译，只是传不同的参数给数据库服务器；而如果把变量值拼接到 sql 里，则每次传给数据库服务器的 sql语句重复的可能性非常低，数据库服务器每次都要编译一次，造成性能下降。