首页 / C# / LinqtoSql的执行可能无法复用查询计划

LinqtoSql的执行可能无法复用查询计划

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了LinqtoSql的执行可能无法复用查询计划，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4655字，纯文字阅读大概需要7分钟。

内容图文

Sql Server 在执行一条查询语句之前都对对它进行“编译”并生成“查询计划”，查询计划告诉Sql Server的查询引擎应该用什么方式进行工作。Sql Server会根据当前它可以收集到的各种信息(例如内存大小，索引的统计等等)把一条查询语句编译成它认为“最优”的

　　Sql Server在执行一条查询语句之前都对对它进行“编译”并生成“查询计划”，查询计划告诉Sql Server的查询引擎应该用什么方式进行工作。Sql Server会根据当前它可以收集到的各种信息(例如内存大小，索引的统计等等)把一条查询语句编译成它认为“最优”的查询计划。很显然，得到这样一个查询计划需要消耗CPU资源，而大部分的查询语句每次经过编译所得到的查询计划往往是相同的，因此除非指定了RECOMPILE选项，Sql Server在执行查询语句时，会对查询计划进行缓存――也就是说，如果是相同的查询语句，Sql Server只会对它进行一次编译操作，然后在每次执行时对查询计划进行复用。查询计划如果无法复用，则会在相当程度上降低数据库性能――因为过多的CPU被消耗在查询语句的编译上。各种提及数据库查询优化的资料上大都会提到这一点，我们往往通过查看性能计数器的某些统计，或者Sql Server系统表中的一些记录，就可以判定您的数据库应用是否出现了这个问题。

　　对于存储过程来说，复用查询计划是轻而易举的。不过对于那些喜欢在程序代码中拼接Sql字符串的朋友来说，日子就有些不好过了。Sql Server是根据您传入的Sql语句来缓存查询计划的，如果您“强行”拼接了Sql字符串并交给Sql Server执行，那么查询计划被复用的可能性微乎其微。因此，我们绝对应该杜绝拼接字符串的行为，因为这不仅仅造成了传统的Sql注入!而那些习惯相对较好的朋友，则会使用带参数的Sql语句，在交给Sql Server执行时就可能复用查询计划。因为和调用存储过程相比，发送带参数的Sql语句只是将使用了sp_executesql命令而已，每次执行的查询语句还是相同的。

　　问题何在?

　　对于复用查询计划的问题，在上文中我说了这么一句话：“……使用带参数的Sql语句，在交给Sql Server执行时就可能复用查询计划……”。我为什么要说“可能”?因为即时使用带参数的Sql语句，在某些情况下我们还是无法对查询计划进行复用。这是怎么一回事儿呢?我们还是直接从Linq to Sql来产生Sql语句，然后观察Sql Server的行为吧。

　　请看以下的代码(示例所操作的数据表与《在Linq to Sql中管理并发更新时的冲突(2)：引发更新冲突》一文相同)：

以下是引用片段：
　　LinqToSqlDemoDataContext dataContext = new LinqToSqlDemoDataContext();
　　dataContext.Log = Console.Out;
　　Video video1 = dataContext.Videos.SingleOrDefault(
　　v => v.Introduction == "Hello");
　　Video video2 = dataContext.Videos.SingleOrDefault(
　　v => v.Introduction == "Hello World");
　　Console.ReadLine();

　　还是查看输出：

以下是引用片段：
　　SELECT [t0].[VideoID], [t0].[Introduction], [t0].[SiteID]
　　FROM [dbo].[Video] AS [t0]
　　WHERE [t0].[Introduction] = @p0
　　-- @p0: Input NVarChar (Size = 5; Prec = 0; Scale = 0) [Hello]
　　-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1
　　SELECT [t0].[VideoID], [t0].[Introduction], [t0].[SiteID]
　　FROM [dbo].[Video] AS [t0]
　　WHERE [t0].[Introduction] = @p0
　　-- @p0: Input NVarChar (Size = 11; Prec = 0; Scale = 0) [Hello World]
　　-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1

　　两局Sql语句完全相同，按我们刚才的说法，Sql Server应该缓存了查询计划。但是我们通过查看sys.syscacheobjects的相关数据可以看出，事情并非如同我们想象的那样：

以下是引用片段：
　　SELECT cacheobjtype, sql FROM sys.syscacheobjects;
　　DBCC freeproccache;

　　LinqtoSql的执行可能无法复用查询计划 - 文章图片

　　请注意上图中被选中的两条记录，它表明了Sql Server并没有缓存执行计划。

　　为什么?这两次执行究竟有什么区别?通过Linq to Sql很容易看出，两次执行所用到的参数不同。更进一步，如果对比Linq to Sql输出的缓存以及sys.syscacheobjects视图中的记录，就会发现：其实仅仅是参数的尺寸不同。

　　没错，就是这个原因。在使用ADO.NET时，如果SqlParameter的Type是nvarchar，并且没有指定Size属性，则可能就会因为具体参数的尺寸不同而造成查询计划无法复用的结果。这一点，很多人都忽视了。

　　优化方案

　　在使用ADO.NET进行开发时，该问题其实很容易解决。我们只要指定SqlParameter的Size属性即可。由于每次指定了一个固定的参数尺寸，Sql Server就能够复用查询计划了。

　　不过我们现在在使用Linq to Sql，又该怎么做呢?嗯，我们可以为XXXXDataContext重写(override)SubmitChanges方法，在其中获得需要执行的SqlCommand对象(具体方法请参考《在Linq to Sql中管理并发更新时的冲突(1)：预备知识》一文)，获得其中的SqlParameter参数，并设定它们的Size属性。我们可以使用Custom Attribute来标注应该为哪个属性设置什么样的Size，如果再结合AOP，哈哈……

　　等等，先别想那么远。即使得到了SqlCommand对象，它所生成的Sql语句是以@p0、@p1作为参数名，您知道该修改哪个SqlParameter对象吗?再者，SubmitChanges方法只是提交我们做出的修改，但是在一般的系统中，查询操作的次数和性能消耗大大超过修改操作，而重写了SubmitChangeds方法又不能影响我们的优化操作……

　　因此，我想在这里说的是：这个问题我们没法进行优化。

　　不过我们还是幸运的，因为我根据我的经验，似乎在查询条件中使用长度不等的字符串作为参数的情况并不多见。不是么?

　　点击查看原文>>



内容总结

以上是互联网集市为您收集整理的LinqtoSql的执行可能无法复用查询计划全部内容，希望文章能够帮你解决LinqtoSql的执行可能无法复用查询计划所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/534904.html

来源：【匿名】