从整个查询计划来看,主要开销都花在了图5的那个部分——两个“聚集索引扫描”。 查看一下这两个数“聚集索引扫描”,搞什么飞机呢?
奇怪了,查询语句里面没有Log_Nwtwork_circs 这个表啊,再仔细分析一下这个执行计划,嫌疑最大的就是view_Log_Network_circsByUnit这个视图了。 查看一下这个试图的定义: CREATE VIEW [dbo].[view_Log_Network_circsByUnit]
看着有点晕是吧,那么看看下图
3、优化 那就只能针对这个试图调优啦。仔细观察这个试图,实际上就涉及到一个表 Log_Network_circs,下面是该表的表结构: CREATE TABLE [dbo].[Log_Network_circs](
数据量有489957条记录,不算太大。 根据 3、经常与其他表进行连接的表,在连接字段上应该建立索引; 感觉上得在 node_code 和 end_time 这两字段上建立一个复合索引,大概定义如下: CREATE INDEX [idx__Log_Network]
保险起见,我把需要调优的语句copy到一个文件里,然后打开“数据库引擎优化顾问”,设置好数据库,得出以下调优结果:
CREATE STATISTICS [_dta_stat_559341057_6_2] ON [dbo].[Log_Network_circs]([end_time], [node_code]) 嗯,结果差不多,具体参数再说。 按照“数据库引擎优化顾问”给出的建议,建立 STATISTICS 和 INDEX 。 再看看优化后的执行计划
明显查询 view_Log_Network_circsByUnit 这个视图的执行计划不一样了。
不看广告,看疗效,使用统计功能。执行以下语句: SET STATISTICS IO 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 毫秒。 逻辑读取数,总执行时间都大大缩减,开来调优还是挺成功的 :) 。 |