最近一些时间在BI的论坛上看到一些朋友的提问，有一些是关于sql语句的问题
虽然重点不是问sql注入的，但这些朋友的的程序的确存在sql注入的问题，这是很危险的。

关于Sql注入的基本概念，相信不需多说，大家都清楚，经典的注入语句是' or 1=1--
单引号而截断字符串，“or 1=1”的永真式的出现使得表的一些信息被暴露出来，如果sql语句是select * from 的话，可能你整个表的信息都会被读取到，更严重的是，如果恶意使用都使用drop命令，那么可能你的整个数据库得全线崩溃。

当然，现在重点不是讲sql注入的害处，而是说说如何最大限度的避免注入问题。

sql注入的存在在最大危害，是sql的执行语句没有和控制语句分开，我们想要select一些东西，但用户可能拼出' or 1=1甚至再加上delete/update/drop，后来是属于控制语句了，所以要避免sql的注入，就必须把查询语句与控制语句分开。

SqlParameter给我们提供了一个很好的类，有了它，我们可以不现拼接字符串，也可以不再担心单引号带来的惨剧，因为，这一切会有人来为我们完成的。

简单的给个示例

传统的查询语句的sql可能为
string sql="select * from users where user_id='"+Request.QueryString["uid"]+"'";
很显然，我们在这里拼接了字符串，这就给sql注入留下了可乘之机。

现在，我们要改写这样的语句，使用SqlParameter来做

SqlCommand SqlCmd = new SqlCommand(sql, SqlConn);
SqlParameter _userid = new SqlParameter("uid", SqlDbType.Int);
 _userid.Value = Request.QueryString["u_id"];
SqlCmd.Parameters.Add(_userid);

这样，我们可以保证外接参数能被正确的转换，单引号这些危险的字符也会转义了，不会再对库造成威胁。

当然，这仅是一个示例而已，在真实的情况下，可能你还要对 Request.QueryString["u_id"]进行必要的检测与分析，这样才安全

所以，使用参数化的sql语句，是一种很好的做法，不过，我们也还有更好的办法，那就是使用参数化的存储过程，如果你有兴趣，可以继续探讨。