数据库 16

数据库针对重点语句调索引,诊断系列

    现在很多用户被数据库的慢的问题所困扰,又苦于花钱请一个专业的DBA成本太高。软件维护人员对数据库的了解又不是那么深入,所以导致问题迟迟不能解决,或只能暂时解决不能得到根治。开发人员解决数据问题基本又是搜遍百度各种方法尝试个遍,可能错过诊断问题的最佳时机又可能尝试一堆方法最后无奈放弃。

    现在很多用户被数据库的慢的问题所困扰,又苦于花钱请一个专业的DBA成本太高。软件维护人员对数据库的了解又不是那么深入,所以导致问题迟迟不能解决,或只能暂时解决不能得到根治。开发人员解决数据问题基本又是搜遍百度各种方法尝试个遍,可能错过诊断问题的最佳时机又可能尝试一堆方法最后无奈放弃。

  上一篇我们说了索引的重要性,一个索引不仅能让一条语句起飞,也能大量减少系统对CPU、内存、磁盘的依赖。我想上一篇中的例子可以说明了。给出上一篇和目录文链接:

    本系列文章主要和企业IT运维人员或数据库从业者分享,如何用最快的方式解决数据库出现的问题?当问题出现时应该有的解决思路和本能的判断。让数据库问题出现时,我们不再那么慌乱,不再毫无头绪。

    本系列文章主要和企业IT运维人员或数据库从业者分享,如何用最快的方式解决数据库出现的问题?当问题出现时应该有的解决思路和本能的判断。让数据库问题出现时,我们不再那么慌乱,不再毫无头绪。

SQL SERVER全面优化——-索引有多重要?

    另外针对目前企业对数据库的应用,阐述一些最佳实践,90%的系统问题,由10%的问题导致,这里没有高大上的技术,有的只是解决那10%问题的经验。

    另外针对目前企业对数据库的应用,阐述一些最佳实践,90%的系统问题,由10%的问题导致,这里没有高大上的技术,有的只是解决那10%问题的经验。

SQL SERVER全面优化——-Expert for SQL Server 诊断系列

 

  

  书接前文,我们知道了索引的重要,也知道了索引怎么加,那么我们应该往那些语句加?语句一条一条漫无目的的优化么?我怎么找出系统的问题语句?怎么样的一个优先级? 

  很多对数据库了解不是很多的人,也许一片茫然!还真不知道,那么多存储过程,那么多程序语句,我总不能都看一遍吧?

  对数据库有些了解的人可能会知道用profiler,系统视图等,这是个不错的方式!

  但是个人觉得这些不够直观,还是不能抓住重点,如果业务多变也会消耗大量时间。

 

  

  所谓工欲善其事,必先利其器!那么本篇我利用 Expert for
sqlserver 讲述怎样抓住重点语句来优化你的系统!**

  

  首先还是上座驾:

  

  数据库 1

 

  

————–博客地址—————————————————————————————

Expert 诊断优化系列 

 

 

废话不多说,直接开整—————————————————————————————–

  本文选用的例子为一个服务器高配,跑了一个小业务,硬件资源充足,但是语句执行很慢!(32CPU,32G内存跑了个只有10G
数据文件的库)

  下面简单的一个展示:

  数据库 2

  数据库 3

  数据库 4

 

 

   性能计数器指标请参见前文,本例中磁盘队列全天小于2,内存充足,CPU使用60%略有压力(主要是缺失索引导致)

  下面看一下总体的语句执行情况:

  数据库 5

  

  语句可以看出超过1-3秒的语句有近8W次,3-5秒
5-10秒均接近2W,10秒以上的也有1W+,可见充足的资源配置下系统语句仍然很慢!

    

    

– 语句优先级 

  前面很多文章中都已经介绍过了,优化一定要针对重点语句,优化10条执行频率低的语句效果不及半条高频语句。那么找到系统中的高频语句就是优化的重中之重!

   直接上图!

  数据库 6

 

    

   图中按照语句的执行次数排序,这也强烈符合我的优化套路,可以看出系统中执行频率最高的语句,平均执行时间都在3秒左右甚至更长,逻辑读都很高,但是影响的行数很少。这就是典型的缺少索引的情况!

 

   高能提示:
看到这样的一个统计界面,你是否知道如何下手了?怎么样的一个优先级?
没错
次数从高往低,来吧!开整!

  根据个人习惯也可以按照逻辑读/写,cpu消耗等排出优先级。

 

     Expert工具下载链接: 

     Expert工具下载链接: 

针对语句调索引

  拿到了重点语句,那么我们就从重点语句下手详细分析一下。上一篇已经介绍了简单粗暴的添加索引,简单粗暴大概能应对80%的场景了,但是也要有一些注意!下面新手看官们要认真体会了!

  数据库 7

 

   数据库 8

 

  我们看到了缺失索引的提示,这就和前文介绍执行计划的大绿字是一个个东西。这里不再详细介绍。那么拿到这个索引缺失我们就直接创建么?前文中告诉你们的答案是直接创建!新的文章中当然要学点新东西!创建前请先核实一下索引!何为核实一下呢?
首先我们看一下执行计划!由于执行计划比较大只贴出消主要耗部分~

  数据库 9

 

  数据库 10

 

 

  执行计划看出,缺失语句主要消耗在两部分,都是这个customer表,index
scan
说明有相关字段的索引,但是不是最优的!那么提示的索引算是正确(字段验证这里就忽略了),那么现在可以创建了?
还需要再核查几个地方!

 

要创建索引的表有多少数据?

 

  数据库 11

  

  表上有150W+数据 确实适合创建索引!

是否有这个类似索引?

  那么表上现在有什么索引呢?是新创建还是修改原有索引呢?

   数据库 12

 

  一堆索引…一屏没截下….但是你会发现一个覆盖索引都没有?也没有针对这条语句的最优索引!
也许这个系统的维护人员知道索引的重要性,但是不知道怎么创建一个最优的索引,HOHO
让他看看上篇文章就好了!

  那么这回可以直接创建提示索引就OK了吧? 答案是大写的“NO”! 还需要你的细心!

  

创建的索引是否能使用? 

  前面 SQL
SERVER全面优化——-写出好语句是习惯 已经提到过,where条件的字段中不能使用函数,不能有隐式转换,也不能用
like “%XXXX%” 这样就不能用索引查找seek了!
我们要看一下是否是提示的索引不能使用!

   

  如果你仔细的看了前文,你会反问:不能用不是就不提示了么?
哈哈,真是认真,确实是这样!这里只是个需要细心的温馨提示!

  但是每一篇文章重要更深入一下么,对吧!
前面看到原计划中customer表使用了index scan ,细心的看官们会发现还有个key
lookup,index scan + key lookup 你不觉得奇怪么?

  数据库 13

 

  我们看一下具体的语句:语句太长,只贴where 部分了  

 数据库 14

 

  我们可以看到customername 确实使用了 like ”%%“
无法使用seek,但是companyid 和createdate 可以使用索引呀~所以我们再看一下
提示出的索引: 

CREATE NONCLUSTERED INDEX [EFS_IX_Customer_b87864c46d0f4d3ca4ad4e4db8232063]
ON [dbo].[Customer] ([CompanyId],[CreateDate])
INCLUDE ([Id],[CustomerId],[CustomerName],[Project],[IndustryOneId],[IndustryTwoId],[SourceId],[StateId],[TypeId],[ProtectId],[Audit],[delFlag])
GO

  还是比较智能吧~这回你可以创建这个索引了!

  

  

  还得啰嗦一句:覆盖索引虽好,但创建要注意,不要把过多的列放在索引里。个人建议索引的筛选列+包含列不要超过表字段的1/3
,纯属个人建议不是那么绝对。

   

  文章至此已经在上一篇的基础上又做了一些细节的说明。看官们可以按照优先级动手了。

 

 

 

大面积创建缺失索引

  如果系统完全没有过保养,表上基本没有创建过什么索引,那么上面的创建方式一样很伤体力,这里还有一种简单粗暴的方式for
you!

  数据库 15

 

 

  大批量创建索引切记不要看到就创建,一定是影响、开销、次数都很高的,并且要优化合并生成的脚本,也就是上一篇提到的精简索引!

   

 

 

– 根据执行计划创建

  这种方式和根据语句创建有异曲同工之妙,但不同的是一般的收集工具只收集1秒以上的语句。默认超过1秒才算慢,但是系统中有些语句执行不到一秒,但非常高频,这也是需要关注的一大类!
限于篇幅这里就不展开说了!

  数据库 16

 

————–博客地址—————————————————————————————

Expert 诊断优化系列 

 

 


 

  总结 :
往往一个系统的整体缓慢都是因为索引问题导致的,优化索引是对你系统最简单的保养!

     
不要小看一条语句的威力,一条语句足可以让你的系统彻底无法工作!

     相反优化一条重要的高频语句就可以让你的系统变的流畅!

     

     优化索引要有自己的方法,不能逮到一条做一条,效率又差又可能抓不住重点。

     每个人优化都有自己的一套方法,只有是够系统,够全面就可以。本文只是简单介绍自己的优化方式,不喜勿喷~

 

 Expert工具下载链接: 

相关文章链接 : 

    本系列主要通过 Expert for
sqlserver 
 工具讲解,分为以下几个大块:

    本系列主要通过 Expert for
sqlserver 
 工具讲解,分为以下几个大块:

SQL SERVER全面优化——-索引有多重要?

 

 

SQL SERVER全面优化——-写出好语句是习惯

写给运维兄弟

  

写给运维兄弟

  

Expert 诊断优化系列——————语句调优三板斧

 —————————————————————————————————-

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

  引用高大侠的一句话 :“拒绝SQL Server背锅,从我做起!”

为了方便阅读给出系列文章的导读链接:

Expert 诊断优化系列——————你的CPU高么?

    

Expert 诊断优化系列——————你的CPU高么?

    

SQL SERVER全面优化——-Expert for SQL Server 诊断系列

 

Expert 诊断优化系列——————内存不够用么?

    

Expert 诊断优化系列——————内存不够用么?

    

Expert 诊断优化系列——————冤枉磁盘了

    

Expert 诊断优化系列——————冤枉磁盘了

    

Expert 诊断优化系列——————语句调优三板斧

    

Expert 诊断优化系列——————语句调优三板斧

    

Expert 诊断优化系列——————透过等待看系统

 

Expert 诊断优化系列——————透过等待看系统

 

Expert 诊断优化系列——————给TempDB 降温

 

Expert 诊断优化系列——————给TempDB 降温

 

Expert 诊断优化系列——————锁是个大角色

 

Expert 诊断优化系列——————锁是个大角色

 

SQL SERVER全面优化——-写出好语句是习惯

 

SQL SERVER全面优化——-写出好语句是习惯

 

SQL SERVER全面优化——-索引有多重要?

 

SQL SERVER全面优化——-索引有多重要?

 

Expert 诊断优化系列————-针对重点语句调索引

 

Expert 诊断优化系列————-针对重点语句调索引

 

数据库的运维策略脚本篇(内附脚本,无私分享)

 

数据库的运维策略脚本篇(内附脚本,无私分享)

 

数据库优化案例——————某市中心医院HIS系统

 

数据库优化案例——————某市中心医院HIS系统

 

性能优化实战案例——助力某移动OA系统

 

性能优化实战案例——助力某移动OA系统

 

数据库高可用实战案例——-架构优化之清爽一夏

 

数据库高可用实战案例——-架构优化之清爽一夏

 

数据库实战案例—————记一次TempDB暴增的问题排查

 

 

数据库实战案例—————记一次TempDB暴增的问题排查

 

数据库优化案例——————某知名零售企业ERP系统