网站优化快照,现在建设网站落后了,服装公司网站源码,做网站的相关术语查询计划 Sql Server在执行一条查询语句之前都对对它进行“编译”并生成“查询计划”#xff0c;查询计划告诉Sql Server的查询引擎应该用什么方式进行工作。Sql Server会根据当前它可以收集到的各种信息#xff08;例如内存大小#xff0c;索引的统计等等#xff09;把一条…查询计划 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.1SELECT [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; 请注意上图中被选中的两条记录它表明了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重写overrideSubmitChanges方法在其中获得需要执行的SqlCommand对象具体方法请参考《在Linq to Sql中管理并发更新时的冲突1预备知识》一文获得其中的SqlParameter参数并设定它们的Size属性。我们可以使用Custom Attribute来标注应该为哪个属性设置什么样的Size如果再结合AOP哈哈…… 等等先别想那么远。即使得到了SqlCommand对象它所生成的Sql语句是以p0、p1作为参数名您知道该修改哪个SqlParameter对象吗再者SubmitChanges方法只是提交我们做出的修改但是在一般的系统中查询操作的次数和性能消耗大大超过修改操作而重写了SubmitChangeds方法又不能影响我们的优化操作…… 因此我想在这里说的是这个问题我们没法进行优化。 不过我们还是幸运的因为我根据我的经验似乎在查询条件中使用长度不等的字符串作为参数的情况并不多见。不是么转载于:https://www.cnblogs.com/JeffreyZhao/archive/2007/11/21/linq-to-sql-cannot-cache-compiled-plan.html
