SQL SERVER性能调优之五(CPU性能分析)
(一)概述
(1)CPU对一台数据库服务器来说,是非常重要的资源。废话少说大家都懂的。
(2)如何监控CPU性能。
2.1 可以使用system perfmon收集Processor:% Processor Time性能计数器,可以参见另一篇文章
2.2使用SQL Server Performance Dashboard。
(二)什么原因会导致CPU性能问题?
(1)大量消耗CPU的运算,如哈希运算,排序运算。
(2)执行计划的编译和重编译。
(3)缺乏索引的大量IO操作也会引起额外的CPU消耗。
(4)并行操作。
等等。。。。
(三)具体手段
(1)几个重要的等待,先确定服务器级别的等待。
SELECT wait_type, Sum (signal_wait_time_ms) AS TotalSignalWaitTime FROM sys.dm_os_wait_stats GROUP BY wait_type ORDER BY 2 DESC |
CXPACKET等待:等待多个线程同步,会出现此等待。
SOS_SCHEDULER_YIELD:放弃CPU,并等待继续执行。
如果发现大量CXPACKET等待,可能由于并行造成,在OLTP系统,可以考虑降低并行度。
如果发现大量SOS_SCHEDULER_YIELD等待,可能说明你的CPU存在瓶颈。
(2)几个重要的计数器
sql statistics: sql compilations/sec 每秒的查询编译次数
sql statistics: sql recompilations/sec 每秒的查询重编译次数
如果发现以上两个性能计数器的值非常高,可以CPU性能问题有编译造成。可以采用存储过程封装T-SQL语句,参数化查询,紧急时可以开启数据强制参数化。
(3)语句级别处理
SELECT TOP 10 total_worker_time / execution_count AS [ Avg CPU Time ], ( SELECT Substring (text, statement_start_offset / 2, ( CASE WHEN statement_end_offset = -1 THEN Len( CONVERT (NVARCHAR( max ), text)) * 2 ELSE statement_end_offset END - statement_start_offset ) / 2 ) FROM sys.Dm_exec_sql_text(sql_handle)) AS query_text, * FROM sys.dm_exec_query_stats ORDER BY [ Avg CPU Time ] DESC |
select top 10 (total_logical_reads/execution_count) as avg_logical_reads, (total_logical_writes/execution_count) as avg_logical_writes, (total_physical_reads/execution_count) as avg_phys_reads, Execution_count, statement_start_offset as stmt_start_offset, sql_handle, plan_handle from sys.dm_exec_query_stats order by (total_logical_reads + total_logical_writes) Desc |
使用该查询可以查询CPU和IO消耗最高的10个语句,可以逐一分析,是否可以更改写法或者适当添加索引,降低CPU使用率(一般高CPU和高IO关联,所以可以想办法先降低IO,直观的处理,就是减少语句的逻辑读)。
(四)总结
CPU优化是一个长期的过程,需要定义将当前的性能计数器和基线对比,尽早的发现问题,CPU出现性能问题,有时候也不一定代表就是CPU出现瓶颈了,可能预示其他硬件出现故障了,或者索引被意外删除了,网站受到攻击等等,所以CPU监控至关重要。
T-SQL之哈希索引
(一)问题提出
1,当表中一个字段过长时,建立索引就不适合的了,建立索引的一个原则就是索引不能太宽。
2,对于varchar(max)、nvarchar(max) 和 varbinary(max) 大值数据类型根本就不能建立索引。
3,对于这个情况怎么办呢?
4,哈希索引就派上了用场。
(二)示例代码
-建立测试表 CREATE TABLE hash_index ( id INT IDENTITY(1, 1) PRIMARY KEY , name VARCHAR ( max ) ) go --插入10000测试数据 WITH cte AS ( SELECT NUMBER + 1 AS NUMBER FROM master..spt_values a WHERE a.TYPE = 'P' AND NUMBER < 100) INSERT INTO hash_index ( name ) SELECT Cast (Newid() AS VARCHAR (50)) + Cast (Newid() AS VARCHAR (50)) + Cast ( Newid() AS VARCHAR (50)) + Cast (Newid() AS VARCHAR (50)) + Cast ( Newid() AS VARCHAR (50)) + Cast (Newid() AS VARCHAR (50)) + Cast ( Newid() AS VARCHAR (50)) FROM cte a CROSS JOIN cte b go --增加计算列 ALTER TABLE hash_index ADD cs_name AS Checksum( name ); go --增加索引 CREATE INDEX idx_name ON hash_index(cs_name) |
(三)查询示例
--查询一表扫描 SELECT * FROM hash_index WHERE name = 'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5' --查询二哈希索引 SELECT * FROM hash_index WHERE name = 'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5' AND cs_name = Checksum( 'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5' ) |
(四)对比性能消耗
表 'hash_index'。扫描计数 1,逻辑读取 340 次,物理读取 4 次,预读 133 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。
表 'hash_index'。扫描计数 1,逻辑读取 5 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。