如何找出你性能最差的SQL Server查询

原文:如何找出你性能最差的SQL Server查询

我经常会被反复问到这样的问题:”我有一个性能很差的SQL Server。我如何找出最差性能的查询?“。因此在今天的文章里一些让你很容易找到问题答案的信息和向导。

问SQL Server!

SQL Server的一个优点是它本身能回答几乎所有你的问题,因为SQL Server在各个DMV和DMF里存储了很多故障排除信息。另一方面这也是个缺点,因为你必须知道各个DMV/DMF,还有如何把它们解释和关联在一起。

至于你的最差性能SQL Server查询的一个最重要的DMV是sys.dm_exec_query_stats。对于每个缓存的执行计划,SQL Server存储了这个执行计划在运行时的详细信息。另外SQL Server告诉你这个查询消耗的CPU时间和I/O读取。当我对性能很差的SQL Server进行故障排除时,这是我经常使用的基本DMV之一。

让我们进入sys.dm_exec_query_stats!

当你对sys.dm_exec_query_stats进行一个简单的SELECT查询,你会得到有很多不同列的一个非常广泛的记录集——有大量的不同数字。

 

我们来仔细看下它们。对于每个缓存的执行计划,SQL Server给你下列度量的信息:

  • Worker Time (columns …_工作者时间)
  • Physical Reads (columns …_物理读)
  • Logical Writes (columns …_逻辑写)
  • Logical Reads (columns …_逻辑读)
  • SQLCLR Time (columns …_公共语言运行时间)
  • Elapsed Time (columns …_运行时间)
  • Row Count (columns …_行数)

对于每个度量,你得到4个集合信息的不同列:

  • 总值(Total value)
  • 上个值(Last value)
  • 最小值(Min value)
  • 最大值(Max value)

手上有了这些信息找出你性能最差的查询是什么。但首先你要知道什么是你的性能瓶颈——CPU还是I/O限制?如果你的性能瓶颈是CPU限制,你可以用下列查询问SQL Server根据CPU消耗列出前5个最差性能的查询:

-- Worst performing CPU bound queries
SELECT TOP 5
    st.text,
    qp.query_plan,
    qs.*
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY total_worker_time DESC
GO

你可以看到这里我使用了简单的ORDER BY total_worker_time DESC来返回CPU密集的查询。另外也通过调用sys.dm_exec_sql_textsys.dm_exec_query_plan DMF来抓取SQL语句和执行计划本身。下列代码显示如何依据I/O消耗来找出你性能最差的查询。 

 1 -- Worst performing I/O bound queries
 2 SELECT TOP 5
 3     st.text,
 4     qp.query_plan,
 5     qs.*
 6 FROM sys.dm_exec_query_stats qs
 7 CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) st
 8 CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
 9 ORDER BY total_logical_reads DESC
10 GO

当在你面前有SQL语句和执行计划时,你可以进一步分析查询找出是什么引起高CPU或I/O消耗。

小结

SQL Server是个惊艳的产品:它可以立即给你问题的很好答案。你只要知道在哪里找你的答案。至于性能很差的查询,你总应该通过分析DMV sys.dm_exec_query_stats开始,在这里SQL Server保存里你执行计划运行时统计信息。

感谢关注!

时间: 2024-10-29 16:25:35

如何找出你性能最差的SQL Server查询的相关文章

Sql Server 查询性能优化之走出索引的误区分析_MsSql

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的

分析Sql Server查询性能优化之走出索引的误区

误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的观点是错误的,SQL Server查询优化器是基于开销进行选择的优化器,通过一系列复杂判断来决定是否使用索引.使用什么类型索引.使用那个索引.SQL Server内部维护着索引列上的数据的统计,统计信息会随着索引列内容的变化而变化,索引的有效期完全取决于索引列上的统计信息,随着数据的变化关于索引的检索机制也随之变化.对于查询优化器来说始终保持查询开销最低始终是其的不二选择,如果一个非聚集索引的列上有大量的重复值,

Sql Server 查询性能优化之走出索引的误区分析

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的

收集并存储性能监控器数据到SQL Server表

server|监控|数据|性能 收集并存储性能监控器数据到SQL Server表 ? ? 当我们需要监控数据库SQL Server服务器性能的时候,有些数据库管理人员可能会选择Windows为我们提供的'性能'监控器来操作(开始菜单à管理工具à性能). 如果可以将性能监控器采集到的数据记录到SQL Server 的数据库表中去,很多工作对我们来说也许方便得多.开启性能监控器点击开始菜单à运行à执行(perfmon) 或者 开始菜单à管理工具à性能 ? 就可以看到下面的画面了 ?定义性能监控器LO

SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用

原文:SET STATISTICS IO和SET STATISTICS TIME 在SQL Server查询性能优化中的作用 近段时间以来,一直在探究SQL Server查询性能的问题,当然也漫无目的的查找了很多资料,也从网上的大神们的文章中学到了很多,在这里,向各位大神致敬.正是受大神们无私奉献精神的影响,所以小弟也作为回报,分享一下关于SET STATISTICS IO和SET STATISTICS TIME这两条T_SQL命令,在查询优化性能中的作用.       首先我想说明一下这篇文章

SQL Server 查询性能优化 相关文章

来自: SQL Server 查询性能优化--堆表.碎片与索引(一) SQL Server 查询性能优化--堆表.碎片与索引(二) SQL Server 查询性能优化--覆盖索引(一) SQL Server 查询性能优化--覆盖索引(二) SQL Server 查询性能优化--创建索引原则(一) SQL Server 查询性能优化--创建索引原则(二) SQL Server 查询性能优化--索引与SARG(一) SQL Server 查询性能优化--索引与SARG(二) SQL Server 查

SQL Server查询性能优化之创建合理的索引(下)

续上一篇SQLServer查询性能优化之创建合理的索引(上) 数据库索引分为聚集索引和非聚集索引,聚集索引就是物理索引,也就是数据的物理的存储顺序,聚集索引的叶子节点就是数据行本身:非聚集索引是逻辑索引,也可以简单的认为是对聚集索引建立的索引,一般来说聚集索引的键就是非聚集索引的叶子节点(在不使用include时). 关于索引的选择 对于索引类型来说没什么好选的,一般来说聚集索引是必须的(有特殊需要的另说),非聚集索引看实际需要灵活建立.因此对于索引来说主要是决定在那些列上建立索引,尤其是对于聚

从性能的角度谈SQL Server聚集索引键的选择

简介 在SQL Server中,数据是按页进行存放的.而为表加上聚集索引后,SQL Server对于数据的查找就是按照聚集索引的列作为关键字进行了.因此对于聚集索引的选择对性能的影响就变得十分重要了.本文从旨在从性能的角度来谈聚集索引的选择,但这仅仅是从性能方面考虑.对于有特殊业务要求的表,则需要按实际情况进行选择. 聚集索引所在的列或列的组合最好是唯一的 这个原因需要从数据的存放原理来谈.在SQL Server中,数据的存放方式并不是以行(Row)为单位,而是以页为单位.因此,在查找数据时,S

Sql Server查询性能优化之不可小觑的书签查找介绍_MsSql

小小程序猿SQL Server认知的成长 1.没毕业或工作没多久,只知道有数据库.SQL这么个东东,浑然分不清SQL和Sql Server Oracle.MySql的关系,通常认为SQL就是SQL Server 2.工作好几年了,也写过不少SQL,却浑然不知道索引为何物,只知道数据库有索引这么个东西,分不清聚集索引和非聚集索引,只知道查询慢了建个索引查询就快了,到头来索引也建了不少,查询也确实快了,偶然问之:汝建之索引为何类型?答曰:... 3.终于受到刺激开始奋发图强,买书,gg查资料终于知道