很多人都知道参数化查询可以避免上面出现的注入问题，比如下面的代码：

 

class Program
{
private static string connectionString = "Data Source=.;Initial Catalog=Test;Integrated Security=True";
static void Main(string[] args)
{
Login("b"， "a");
Login("b' or 1=1--"， "a");
}
private static void Login(string userName， string password)
{
using (SqlConnection conn = new SqlConnection(connectionString))
{
conn.Open();
SqlCommand comm = new SqlCommand();
comm.Connection = conn;
//为每一条数据添加一个参数
comm.CommandText = "select COUNT(*) from Users where Password = @Password and UserName = @UserName";
comm.Parameters.AddRange(
new SqlParameter[]
{
new SqlParameter("@Password"， SqlDbType.VarChar)
{Value = password}，
new SqlParameter("@UserName"， SqlDbType.VarChar)
{Value = userName}，
});
comm.ExecuteNonQuery();
}
}
}

　　实际执行的SQL 如下所示：
　　exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName'，N'@Password varchar(1)，@UserName varchar(1)'，@Password='a'，@UserName='b'
　　exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName'，N'@Password varchar(1)，@UserName varchar(11)'，@Password='a'，@UserName='b'' or 1=1—'
　　可以看到参数化查询主要做了这些事情：
　　1：参数过滤，可以看到 @UserName='b'' or 1=1—'
　　2：执行计划重用
　　因为执行计划被重用，所以可以防止SQL注入。
　　首先分析SQL注入的本质，
　　用户写了一段SQL 用来表示查找密码是a的，用户名是b的所有用户的数量。
　　通过注入SQL，这段SQL现在表示的含义是查找(密码是a的，并且用户名是b的) 或者1=1 的所有用户的数量。
　　可以看到SQL的语意发生了改变，为什么发生了改变呢？，因为没有重用以前的执行计划，因为对注入后的SQL语句重新进行了编译，因为重新执行了语法解析。所以要保证SQL语义不变，即我想要表达SQL是我想表达的意思，不是别的注入后的意思，应该重用执行计划。
　　如果不能够重用执行计划，那么有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询可能变化。
　　在SQL Server 中查询执行计划可以使用下面的脚本：

 

DBCC FreeProccache
select total_elapsed_time / execution_count 平均时间，total_logical_reads/execution_count 逻辑读，
usecounts 重用次数，SUBSTRING(d.text， (statement_start_offset/2) + 1，
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(text)
ELSE statement_end_offset END
- statement_start_offset)/2) + 1) 语句执行 from sys.dm_exec_cached_plans a
cross apply sys.dm_exec_query_plan(a.plan_handle) c
，sys.dm_exec_query_stats b
cross apply sys.dm_exec_sql_text(b.sql_handle) d
--where a.plan_handle=b.plan_handle and total_logical_reads/execution_count>4000
ORDER BY total_elapsed_time / execution_count DESC;
18EFAED775BF4DB9A36C57B39EC6913D