45IT.COM- 电脑学习从此开始!
DIY硬件教程攒机经验装机配置
设计Photoshop网页设计特效
系统注册表DOS系统命令其它
存储主板显卡外设键鼠内存
维修显卡CPU内存打印机
WinXPVistaWin7unix/linux
CPU光驱电源/散热显示器其它
修技主板硬盘键鼠显示器光驱
办公ExcelWordPowerPointWPS
编程数据库CSS脚本PHP
网络局域网QQ服务器
软件网络系统图像安全
页面导航: 首页 > 设计学院 > 网络编程 > 数据库 >

一次SQL Server调优经历(3)

电脑软硬件应用网 45IT.COM 时间:2013-09-05 13:08 作者:佚名

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

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

 

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

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

CREATE VIEW [dbo].[view_Log_Network_circsByUnit] 
AS 
SELECT B.* 
FROM ( 
    SELECT node_code, MAX(end_time) AS end_time 
        FROM Log_Network_circs 
        GROUP BY node_code 
     ) A 
LEFT OUTER JOIN 
      dbo.Log_Network_circs B 
ON 
    A.node_code = B.node_code 
    AND 
          A.end_time = B.end_time

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

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

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

CREATE TABLE [dbo].[Log_Network_circs]( 
    [log_id] [varchar](30) NOT NULL, 
    [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] PRIMARY KEY CLUSTERED 

    [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 这两字段上建立一个复合索引,大概定义如下:

CREATE INDEX [idx__Log_Network] 
ON Log_Network_circs 

    node_code ASC, 
    end_time ASC 
)

保险起见,我把需要调优的语句copy到一个文件里,然后打开“数据库引擎优化顾问”,设置好数据库,得出以下调优结果:

CREATE STATISTICS [_dta_stat_559341057_6_2] ON [dbo].[Log_Network_circs]([end_time], [node_code])

CREATE NONCLUSTERED INDEX [_dta_index_Log_Network_circs_24_559341057__K2_K6] ON [dbo].[Log_Network_circs] 

    [node_code] ASC, 
    [end_time] ASC 
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]

嗯,结果差不多,具体参数再说。

按照“数据库引擎优化顾问”给出的建议,建立 STATISTICS 和 INDEX 。

再看看优化后的执行计划

明显查询 view_Log_Network_circsByUnit 这个视图的执行计划不一样了。

image

不看广告,看疗效,使用统计功能。执行以下语句:

SET STATISTICS IO on; 
SET STATISTICS TIME on; 

(2 行受影响) 
表 'Log_Network_circs'。扫描计数 2,逻辑读取 13558 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'TransmissionUnit_RouterInfo'。扫描计数 0,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'TransmissionUnit_LocalInfo'。扫描计数 3,逻辑读取 6 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'network_listen'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 

SQL Server 执行时间: 
   CPU 时间 = 719 毫秒,占用时间 = 719 毫秒。 

(2 行受影响) 
表 'Log_Network_circs'。扫描计数 2,逻辑读取 9 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'TransmissionUnit_RouterInfo'。扫描计数 0,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'TransmissionUnit_LocalInfo'。扫描计数 3,逻辑读取 6 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 
表 'network_listen'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 

SQL Server 执行时间: 
   CPU 时间 = 0 毫秒,占用时间 = 2 毫秒。

逻辑读取数,总执行时间都大大缩减,开来调优还是挺成功的 :) 。

顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
无法在这个位置找到: baidushare.htm
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码:点击我更换图片
推荐知识