一次SQL Server调优经历

WBOY
WBOYオリジナル
2016-06-07 16:19:01922ブラウズ

您现在的位置:首页>教程>编程开发>mssql数据库 > 一次SQL Server调优经历 一次SQL Server调优经历 感谢 3lian10 的投递 时间:2013-09-06 来源:三联教程 前段时间数据库健康检查发现SQL Server服务器的idle时间变少,IO还是比较空闲,估计是遇到了高CPU占

  您现在的位置:首页 > 教程 > 编程开发 > mssql数据库 > 一次SQL Server调优经历

一次SQL Server调优经历

感谢 3lian10 的投递 时间:2013-09-06 来源:三联教程 

   前段时间数据库健康检查发现SQL Server服务器的idle时间变少,IO还是比较空闲,估计是遇到了高CPU占用的语句了。

  介绍一下背景,我们公司负责运维N多的应有系统,负责提供良好的软、硬件环境,至于应用的开发质量,我们就无能为力了

  解决这个问题,我的思路是:

  找出CPU占用最大的语句。

  分析查询计划。

  优化。

  1、找出语句

  使用SQL Server自带的性能报表(不是报表服务),找出CPU占用最大的语句。如图1所示

一次SQL Server调优经历 三联

  图1 性能报表

  我选取了“性能-按总CPU时间排在前面的查询”,得出以下两张报表,如图2所示:

一次SQL Server调优经历

  图2 性能-按总CPU时间排在前面的查询

  在报表中不能直接把语句Copy出来,非得让我另存为Excel才能Copy语句;而且经常标示不了是语句属于哪个数据库,不爽 :( 。

  费了我九牛二虎之力才找出该条语句在哪个数据库执行,然后马上备份数据库,在另一个非生产数据库上面还原,创造实验环境。

  废话少说,我把语句Copy出来,顺便整理了一下格式。如下:

双击代码全选

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

select*

fromnetwork_listen

where

node_codein

  (

  selectdistinctnode_code

  fromview_Log_Network_circsByUnit

  wherestatus='1'

  ) 

or

node_code=

  (

  selecttop1nodeCode

  fromTransmissionUnit_LocalInfo

  ) 

and

node_code

  (

  selectparentNodeCode

  fromTransmissionUnit_RouterInfo

  wherenodeCode=

      (

      selecttop1nodeCode

      fromTransmissionUnit_LocalInfo

      )

  )

  2、分析语句

  执行计划如下:

  图太大了,将就着看吧 :( .

一次SQL Server调优经历

  图3 查询计划全图

一次SQL Server调优经历

  图4 查询计划1

一次SQL Server调优经历

  图5 查询计划2

一次SQL Server调优经历

  图6 查询计划3

  从整个查询计划来看,主要开销都花在了图5的那个部分——两个“聚集索引扫描”。

  查看一下这两个数“聚集索引扫描”,搞什么飞机呢?

一次SQL Server调优经历

一次SQL Server调优经历

  奇怪了,查询语句里面没有Log_Nwtwork_circs 这个表啊,再仔细分析一下这个执行计划,嫌疑最大的就是view_Log_Network_circsByUnit这个视图了。

  查看一下这个试图的定义:

双击代码全选

1

2

3

4

5

6

7

8

9

10

11

12

13

14

CREATEVIEW[dbo].[view_Log_Network_circsByUnit]

AS

SELECTB.*

FROM(

  SELECTnode_code,MAX(end_time)ASend_time

    FROMLog_Network_circs

    GROUPBYnode_code

  )A

LEFTOUTERJOIN

   dbo.Log_Network_circsB

ON

  A.node_code=B.node_code

  AND

     A.end_time=B.end_time

  看着有点晕是吧,那么看看下图

一次SQL Server调优经历

  3、优化

  SQL写得好不好,咱不说,反正我是不能改SQL的,而且应该可以判断出整个查询最耗时的地方就是用在搞这张试图了。

  那就只能针对这个试图调优啦。仔细观察这个试图,实际上就涉及到一个表 Log_Network_circs,下面是该表的表结构:

双击代码全选

1

2

3

4

5

6

7

8

9

10

11

12

13

CREATETABLE[dbo].[Log_Network_circs](

  [log_id][varchar](30)NOTNULL,

  [node_code][varchar](100)NULL,

  [node_name][varchar](100)NULL,

  [server_name][varchar](100)NULL,

  [start_time][datetime]NULL,

  [end_time][datetime]NULL,

  [status][varchar](30)NULL,

CONSTRAINT[PK_LOG_NETWORK_CIRCS]PRIMARYKEYCLUSTERED

(

  [log_id]ASC

)WITH(PAD_INDEX =OFF,STATISTICS_NORECOMPUTE =OFF,

IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS =ON,ALLOW_PAGE_LOCKS =ON)ON[PRIMARY]

)ON[PRIMARY]

  数据量有489957条记录,不算太大。

  根据 3、经常与其他表进行连接的表,在连接字段上应该建立索引;

  感觉上得在 node_code 和 end_time 这两字段上建立一个复合索引,大概定义如下:

双击代码全选

1

2

3

4

5

6

CREATEINDEX[idx__Log_Network]

ONLog_Network_circs

(

  node_codeASC,

  end_timeASC

)

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。