TSQL七个性能杀手.pdfVIP

TSQL 的七个性能杀手 我们不仅要求代码的可读性,同时也必须要求代码的性能非常良好. 下面介绍三个写代码时的常见规范.这些规范是累加的.如果全部采用了这三个规 范,那么将会带来非常好的性能.忽略或者不参照其中任意一个可能会导致性能下 降. 1.根据数据结构编写代码.如果需要存放 Datetime 类型的数据,请使用 datetime,而不是 varchar 或者其他数据类型.另外写代码的时候请在适当的地方 也使用到外键约束和其他的方法. 2.根据索引来编写代码.如果在表上存在索引(应该存在),请编写代码的时候可以 保证能够使用到索引.同时也请保证聚簇索引可以使得查询以更有效率的方式执 行 3.根据查询优化器来编写代码.查询优化器是一个令人惊讶的软件.但是如果编写 的代码不能很好地利用查询优化器,比如在视图中嵌套很多视图,将会导致查询优 化器失效.花费一定的精力去理解查询优化器的工作原理,并且按照这个方式去编 写代码,将会得到很好的性能. 接下来,大概讲一下在开发人员编写代码时的一些比较常见或者罕见的错误.请不 要犯这些错误,那么代码将会很好的运行. 使用错误的数据类型 在概念中看起来非常简单,但是在实际的工作中很难实施.OK,继续.采用数据库中 存在的数据类型.在你的参数或者变量中使用这些数据类型.我们知道 SQLServer 支持隐式的数据类型转换.但是当遇到隐式的数据类型转换或者显式 的指定了数据转换,那么实际上在栏位是执行了一个函数.如果在筛选条件(要么 是Where 条件要么是 JOIN 运算)中的栏位上使用了函数,那么实际上是在执行表 扫描.即使在表上存在一个非常好的索引,但是为了使得可以比较数 据,SQLServer 将会对栏位进行了 CAST 转换,那么这个索引是不会被用到的. 不信?看下面的查询吧. 1. SELECT  e.BusinessEntityID,  2.         e.NationalIDNumber  3. FROM    HumanResources.Employee AS e  4. WHERE   e.NationalIDNumber = 112457891;  复制代码 看起来不错,又简单又很好,应该会使用到这个表上的索引,但是实际上呢,看下面 的执行计划吧 这个查询足够的块,并且表也很小,所以运行下来只有 4 个读取操作.注意到上面 的执行计划中出现了一个惊叹号,在属性窗口中会告诉我们为什么 没错,有一个 PlanAffectingConvert 的报警(SQLServer2012 中新出现).简单点说, 是由于我使用了错误的数据类型. 1. SELECT  e.BusinessEntityID,  2.         e.NationalIDNumber  3. FROM    HumanResources.Employee AS e  4. WHERE   e.NationalIDNumber = 112457891;  复制代码 执行计划如下: 这里只产生了 2 个读取操作,而不是 4 个.我意识到我只是在一个小表的性能问题 上取得成功.但是如果表有上百万行的数据呢,哇,我突然意识到我成了一个英雄. 所以结论就是: 使用正确的数据类型. 在 ON 或者 WHERE 字句中使用了函数去作比较. 这里的函数是指大部分情况下对 ON 或者 WHERE 字句中的栏位去使用函数,这 将导致查询不能使用到索引.因为函数的存在,sqlserver 将对数据进行表扫描,这 将使得性能低下.例如 1. SELECT  a.AddressLine1,  2.         a.AddressLine2,  3.         a.City,  4.         a.StateProvinceID  5. FROM    Person.Address AS a  6. WHERE   4444 = LEFT(a.AddressLine1, 4) ;  复制代码 LEFT 函数使得该语句的执行计划如下: 产生了 316 个读取操作(执行时间超过 9 秒钟),是因为必须遍历每一行使得数据 符合这个函数的条件.当然,这也并不是简单的扫描数据.我们可以将该查询修改 成如下格式: 1. SELECT  a.AddressLine1,  2.         a.AddressLine2,