sql-server – SQL Compilations对SQL Server性能的影响有多严重?

前端之家收集整理的这篇文章主要介绍了sql-server – SQL Compilations对SQL Server性能的影响有多严重?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在通过PerfMon的sqlServer:sql Statistics – sql Compilations / sec度量标准分析sql Server 2005和我的实例,我看到平均值大约是170左右.

我掏出sql Profiler并查找SP:编译或sql:编译事件.显然他们不存在.我确实找到了存储过程/ SP:重新编译和Tsql / sql:StmtRecompile事件.我在Profiler中看到的数据量表明这些是错误的事件,但我不确定.

所以我的问题.任何这些的答案都会很棒.

>如何查看sql Server中的编译内容
>我选择了错误的指标吗?在Perfmon或sql Profiler中?
>关于存储过程/ SP:重新编译和Tsql / sqlsql事件探查器中的StmtRecompile事件…它们不包括持续时间度量标准.如果这些事件无法查看对系统的时序影响,我该如何评估这些事件对系统的影响.

解决方法

sql Compilations / sec是一个很好的指标,但只有在与Batch Requests / sec结合使用时才会出现.就其本身而言,每秒的编辑并没有真正告诉你太多.

你看到170.如果每秒批量请求只有200(有点夸大效果)那么是的,你需要深入到原因的底部(很可能是过度使用临时查询和一次性使用计划).但是,如果你的每秒批量需求大约为5000,则每秒170次编译并不坏.一般的经验法则是,Compilations / sec应该比批量请求总数/秒小10%或更少.

如果您真的想要深入了解正在缓存的内容,请运行以下使用相应DMV的查询

select
    db_name(st.dbid) as database_name,cp.bucketid,cp.usecounts,cp.size_in_bytes,cp.objtype,st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

获得所有一次性使用计划(计数):

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

要获得与所有缓存计划相比的一次性计数计划的比率:

declare @single_use_counts int,@multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,@multi_use_counts as multi_use_counts,@single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

对于通过sql Server跟踪捕获的持续时间,它不适用于重新编译事件.看到计划编制造成的持续时间或痛苦并不是那么重要,因为对于逐案情况你无能为力.解决方案是尝试通过计划重用(参数化查询,存储过程等)来限制编译和重新编译.

猜你在找的MsSQL相关文章