如何用参数化SQL语句污染你的计划缓存

你的SQL语句的参数化总是个好想法。使用参数化SQL语句你不会污染你的计划缓存——错!!!在这篇文章里我想向你展示下用参数化SQL语句就可以污染你的计划缓存,这是非常简单的!

ADO.NET-AddWithValue

ADO.NET是实现像SQL Server关系数据库数据访问的.NET框架的组成——有一些严重的副作用。不要误解我——只要你正确使用,ADO.NET一直很棒。你马上就会看到,它很容易被错误使用。我们来看下面实现SQL语句执行的C#代码。

 1 for (int i = 1; i <= 100; i++)
 2 {
 3    val += i.ToString();
 4
 5    cmd = new SqlCommand(
 6       "SELECT * FROM Sales.SalesOrderDetail WHERE CarrierTrackingNumber = @CarrierTrackingNumber",
 7       cnn);
 8    cmd.Parameters.AddWithValue("@CarrierTrackingNumber", val);
 9    SqlDataReader reader = cmd.ExecuteReader();
10    reader.Close();
11 }

我们是聪明的开发者,因此SQL语句本身被参数化,因为ADO.NET框架是地球上最棒的框架,我们使用System.Data.SqlClient.SqlParameterCollection类的AddWithValue方法来提供实际的参数值。我在WHLIE循环里运行那个SQL语句100次,总用不同长度赋予参数值。在Sales.SalesOrderDetail表里CarrierTrackingNumber列定义为NVARCHAR(25)。因此我们可以在基于我们提供的不同字符长度上有上至25个不同数据类型的参数。现在让我们检查下我们SQL语句执行后的计划缓存。

1 SELECT
2     st.text,
3     cp.*
4 FROM sys.dm_exec_cached_plans cp
5 CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
6 GO

现在事情变得有点疯狂:在计划缓存里我们存储了100个不同的执行计划!

对于每个可能的数据类型参数都有1个执行计划——即使当数据类型是NVACHAR(25)AddWithValue方法非常,非常邪恶:基于你提供的参数值派生出数据类型。永远不要使用它!

ADO.NET – SqlDbType.VarChar

因为从我们的错误中我们学到了,现在我们知道ADO.NET的AddWithValue方法的副作用——我们不再用它。现在让我们重写我们的C#程序代码,如下所示定义一个显示的参数数据类型:

 1 for (int i = 1; i <= 100; i++)
 2 {
 3    val += i.ToString();
 4
 5    cmd = new SqlCommand(
 6       "SELECT * FROM Sales.SalesOrderDetail WHERE CarrierTrackingNumber = @CarrierTrackingNumber",
 7       cnn);
 8    cmd.Parameters.Add(new SqlParameter("@CarrierTrackingNumber", SqlDbType.VarChar));
 9    cmd.Parameters["@CarrierTrackingNumber"].Value = val;
10    SqlDataReader reader = cmd.ExecuteReader();
11    reader.Close();
12 }

从代码里你可以看到,ADO.NET现在不能派生参数数据类型了,因为我们已经指定了SqlDbType.Varchar数据类型。让我们再次执行这个SQL语句100次并再次检查下计划缓存:

没有啥改变。问题还是一样:在计划缓存里我们还有100个不一样的的执行计划。现在的问题是ADO.NET只强制数据类型(SqlDbType.VarChar),但不是数据类型的"长度"。有100个不同的长度在计划缓存里你就有100个不同的执行计划。

如果你在你的ADO.NET代码里显式指定参数数据类型,你也要指定它的长度!现在我们来看下一些修正的C#代码。

 1 for (int i = 1; i <= 100; i++)
 2 {
 3    val += i.ToString();
 4
 5    cmd = new SqlCommand(
 6       "SELECT * FROM Sales.SalesOrderDetail WHERE CarrierTrackingNumber = @CarrierTrackingNumber",
 7       cnn);
 8    cmd.Parameters.Add(new SqlParameter("@CarrierTrackingNumber", SqlDbType.VarChar, 100));
 9    cmd.Parameters["@CarrierTrackingNumber"].Value = val;
10    SqlDataReader reader = cmd.ExecuteReader();
11    reader.Close();
12 }

这次我也指定了数据类型的长度——这里是100,现在当我们再次执行SQL语句100次时,最后我们在计划缓存里以1个执行计划且重用了100次来完美收工。这是从SQL Server角度的最终目标。

小结

寓意:ADO.NET是个很棒的数据访问框架,它提供你有用的功能(例如AddWithValue方法),当从SQL Server角度来说你真的要考虑下你在做什么。当你使用参数化SQL语句时,你要尽量显式:你必须地冠以参数值的实际数据类型,还有你想要的获得数据类型长度。

感谢关注!

时间: 2024-11-08 18:43:46

如何用参数化SQL语句污染你的计划缓存的相关文章

使用参数化SQL语句进行模糊查找(转载)

使用参数化SQL语句进行模糊查找 今天想用参数化SQL语句进行模糊查找,一开始的使用方法不正确,摸索了好一会. 1.使用参数化SQL语句进行模糊查找的正确方法: //定义sql语句 string sql = "SELECT StudentID,StudentNO,StudentName FROM Student WHERE StudentName like @StudentName"; //给参数赋值 command.Parameters.AddWithValue("@Stu

谈一谈SQL Server中的执行计划缓存(上)

原文:谈一谈SQL Server中的执行计划缓存(上) 简介     我们平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径.当我们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse).绑定(Bind).查询优化(Optimization,有时候也被称为简化).执行(Execution).除去执行步骤外,前三个步骤之后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而获得结果.但查询

C# 参数化SQL语句中的like和in

在写项目的时候遇到一个问题,sql 语句进行 like in 参数化,按照正常的方式是无法实现的我们一般的思维是: Like 参数:string strSql = "select * from Person.Address where City like '%@add%'";SqlParameter[] Parameters=new SqlParameter[1];Parameters[0] = new SqlParameter("@add", "bre&

【故障处理141119】一次数据库不繁忙时一条sql语句2个运行计划导致业务超时的故障处理

1,故障描写叙述: 一条select有两个运行计划.在sqlplus中运行选择好的运行计划.仅仅要40毫秒.而在程序中运行选择了差的运行计划,要1分23秒左右,导致前台业务超时报错. 2.故障解决: 使用outline固定好的运行计划后攻克了该故障. 3,故障发展顺序: (1),早上一上班,说CRM的一个业务报错,crm应用开发者.接口的.tuxdo.dba集中到一起開始诊断错误. (2),业务返回超时错误 (3),数据库这边抓取AWR报告发现例如以下信息: (4),此时应用开发者也发过来了该条

如何使用SQLPLUS分析SQL语句(查询执行计划跟踪)

方法一:autotrace 1,  connect sys/密码 as sysdba,在sys用户下运行$ORACLE_HOME/sqlplus/admin/plustrce.sql这段sql的实际内容如下:set echo ondrop role plustrace;create role plustrace;grant select  on v_$sesstat to plustrace;grant select on v_$statname to plustrace;grant selec

谈一谈SQL Server中的执行计划缓存(下)

简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优化器解析语句的过程,当将计划缓存考虑在内时,首先需要查看计划缓存中是否已经有语句的缓存,如果没有,才会执行编译过程,如果存在则直接利用编译好的执行计划.因此,完整的过程如图1所示. 图1.将计划缓存考虑在内的过程 图1中我们可以看到,其中有一步需要在缓存中找到计划的过程.因此不难猜出,只要是这一类查

ADO.NET复习总结(3)--参数化SQL语句

1.SQL 注入 2.使用参数化的方式,可以有效防止SQL注入,使用类parameter的实现类SqlParameter Command的属性parameters是一个参数集合. 3.举例<查询学生表学生个数> 代码: using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; us

《Entity Framework 6 Recipes》中文翻译系列 (12) -----第三章 查询之使用SQL语句 (转)

3-2使用原生SQL语句更新 问题 你想在实体框架中使用原生的SQL语句,来更新底层数据存储. 解决方案 假设你有一张如图3-2所示的Payment数据库表,使用实体框架设计器工具创建了一个如图3-2所示的模型. 图3-2 Payment表,包含一个供应商的付款信息 图3-3 包含一个Payment实体的模型 为了在底层的Payment表中执行一句和多句SQL语句,可以使用在DbContext类中的属性Database中的ExecuteSQlCommand()方法. 虽然我们能在模型中查询Pay

参数化SQL

原文:http://www.cnblogs.com/aito/archive/2010/08/25/1808569.html 避免SQL注入的方法有两种:一是所有的SQL语句都存放在存储过程中,这样不但可以避免SQL注入,还能提高一些性能,并且存储过程可以由专门的数据库管理员(DBA)编写和集中管理,不过这种做法有时候针对相同的几个表有不同条件的查询,SQL语句可能不同,这样就会编写大量的存储过程,所以有人提出了第二种方案:参数化SQL语句.例如我们在本篇中创建的表UserInfo中查找所有女性