当前位置:Gxlcms > mysql > SQLServer性能调优之

SQLServer性能调优之

时间:2021-07-01 10:21:17 帮助过:23人阅读

在我们的OLAP的实现中,SQL超级复杂,用了很多的临时表,tempdb在安装时默认选择了安装SQLserver的本地磁盘路径,没有使用磁盘阵列。 在学习PostgreSQL时发现很多专家建议把临时表空间放在SSD上或者使用RAID0+1的方式来提高写入速度,从而提高性能。 因而就

在我们的OLAP的实现中,SQL超级复杂,用了很多的临时表,tempdb在安装时默认选择了安装SQLserver的本地磁盘路径,没有使用磁盘阵列。

在学习PostgreSQL时发现很多专家建议把临时表空间放在SSD上或者使用RAID0+1的方式来提高写入速度,从而提高性能。

因而就选了一个比较复杂的SQL语句进行了相关测试,发现TempDB的存放路径对性能有很大的影响。

测试描述,单个临时表55w行,共生成8张临时表,最后8个临时表做join联接select group by

测试结果如下:

1. 本机磁盘 2X136G 10K SAS硬盘 RAID1

2. EVA4400 36块 15KX300G SAS 磁盘阵列 RAID 0+1


3. EVA4400 36块 15KX300G SAS 磁盘阵列 RAID 5

可以看到把tempdb 放入磁盘阵列可以得到2倍多的性能提升,奇怪的是RAID1+0 没有比RAID5性能高多少。难道EVA已经对写入做了优化?

放入生产环境后,原来Tempdb的平均堵塞时间由原来的300 多毫秒,降低到 9毫秒,报表的性能得到了很大提升,初步看来响应时间降低到原来的50%左右。

另外一个比较重要的优化是把tempdb的数据文件个数设置成多个,数据文件具体数目和数据库CPU的数目一致(注意不是核数)。

另外根据tempdb的大小情况,设置合适初始文件大小和增长率。

查看是否磁盘瓶颈的SQL如下:

SELECT

DB_NAME(fs.database_id) AS [Database Name]

, mf.physical_name

, io_stall_read_ms

, num_of_reads

, CAST(io_stall_read_ms / (1.0 + num_of_reads) AS NUMERIC(10, 1)) AS [avg_read_stall_ms]

, io_stall_write_ms

, num_of_writes

, CAST(io_stall_write_ms / (1.0 + num_of_writes) AS NUMERIC(10, 1)) AS [avg_write_stall_ms]

, io_stall_read_ms + io_stall_write_ms AS [io_stalls]

, num_of_reads + num_of_writes AS [total_io]

, CAST((io_stall_read_ms + io_stall_write_ms) / (1.0 + num_of_reads

+ num_of_writes) AS NUMERIC(10, 1)) AS [avg_io_stall_ms]

FROM

sys.dm_io_virtual_file_stats(NULL, NULL) AS fs

INNER JOIN

sys.master_files AS mf

ON fs.database_id = mf.database_id

AND fs.[file_id] = mf.[file_id]

ORDER BY

avg_io_stall_ms DESC

OPTION

(RECOMPILE) ;

人气教程排行