在我们的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) ;
，
