CPU性能分析
SQL SERVER性能调优之五（CPU性能分析）
（一）概述
（1）CPU对一台数据库服务器来说，是非常重要的资源。废话少说大家都懂的。
（2）如何监控CPU性能。
2.1 可以使用 system perfmon 收集 Processor：% Processor Time性能计数器，可以参见另一篇文章
SQL SERVER性能调优之二（分析服务器的整体性能）
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监控至关重要。
分类: SQL SERVER 性能调优
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 次。
分类: SQL SERVER T-TQL
作者： Leo_wl
出处： http://HdhCmsTestcnblogs测试数据/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息