SQL性能优化前期准备-清除缓存、开启IO统计

如果需要进行SQl Server下的SQL性能优化,需要准备以下内容:

一、SQL查询分析器设置:

1、开启实际执行计划跟踪。

2、每次执行需优化SQL前,带上清除缓存的设置SQL。

平常在进行SQL Server性能优化时,为了确保真实还原性能问题,我们需要关闭SQL Server自身的执行计划及缓存。可以通过以下设置清除缓存。

1 DBCC DROPCLEANBUFFERS  --清除缓冲区
2 DBCC FREEPROCCACHE  --删除计划高速缓存中的元素

3、开启查询IO读取统计、查询时间统计。

SET STATISTICS TIME ON --执行时间
SET STATISTICS IO ON --IO读取

开启设置后,执行SQL效果如下:

针对其中的每个图标节点,鼠标滑上去的时候,可以看到具体的执行信息。如下图:

可以通过查看谓词、对象、输出列表,分析问题点或者创建优化索引等。

当然你也可以换一种查看方式,点击右键选择显示执行计划XML。

还有一点特别说明的是:当你SQL很长逻辑关系很复杂的时候,执行计划会是一个很大的网状关系图,你会发现在右下角有一个加号的按钮,点击后一个缩略图。通过缩略图你可以很方便的定位执行节点,用起来还比较好用。

二、针对SQL Server Profile,SQL查询跟踪器进行分析。

1、打开方式:SQL Server查询分析器->工具,SQL Profile。打开方式截图:

2、连接&特殊设置:

打开后界面如下图:

设置正确连接信息后,点击连接,弹出如下界面。按照图中操作步骤进行设置。

其中DatabaseId、HostName可以在查询分析器中进行查询,脚本如下:

1 SELECT DB_ID()
2 SELECT DB_NAME()
3 SELECT HOST_ID()
4 SELECT HOST_NAME()

实际上HostName就是你的本机计算机名。

最终设置完之后点击运行。正常跟踪的效果如图:

重点关注其中的Duration、Writes、Reads、CPU,分析对象是TextData,及执行的语句。其中Duration为毫秒数,1000即为1秒。

——————————————————————————————————————————

应用总结&建议

上面应用配合方式是:

1、先通过SQL查询跟踪器,跟踪出你所以执行的SQL,然后定位其中Duration比较的SQL 或者超过性能标准的SQl(比如页面访问3s、5s、8s)、报表30s等。

2、将问题SQL在查询分析器中进行分析,主要通过执行计划及IO统计定位耗时占比高及IO读取大的地方,然后逐步的调整SQL逻辑关系(比如添加业务条件过滤缩小集合,建立索引、调整like匹配等),优化后再重新进行跟踪看看是否有效果,最终达到SQL的优化目的。

写到这里,基本上我常用的SQL性能优化的方式就已经讲完了,希望给大家能提供帮助。

绝对干货,转载请注明出处。原文地址

原文地址:https://www.cnblogs.com/micro-chen/p/8426923.html

时间: 2024-11-06 08:10:45

SQL性能优化前期准备-清除缓存、开启IO统计的相关文章

清除缓存、开启IO统计

SQL性能优化前期准备-清除缓存.开启IO统计 如果需要进行SQl Server下的SQL性能优化,需要准备以下内容: 一.SQL查询分析器设置: 1.开启实际执行计划跟踪. 2.每次执行需优化SQL前,带上清除缓存的设置SQL. 平常在进行SQL Server性能优化时,为了确保真实还原性能问题,我们需要关闭SQL Server自身的执行计划及缓存.可以通过以下设置清除缓存. 1 DBCC DROPCLEANBUFFERS --清除缓冲区 2 DBCC FREEPROCCACHE --删除计划

数据仓库中的 SQL 性能优化(Hive篇)

一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化只是针对Hive 0.9版本,而不是后来Hortonwork发起Stinger

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

SQL Select count(*)和Count(1)的区别和执行方式及SQL性能优化

SQL性能优化:http://www.cnblogs.com/CareySon/category/360333.html Select count(*)和Count(1)的区别和执行方式 在SQL Server中Count(*)或者Count(1)或者Count([列])或许是最常用的聚合函数.很多人其实对这三者之间是区分不清的.本文会阐述这三者的作用,关系以及背后的原理. 往常我经常会看到一些所谓的优化建议不使用Count(* )而是使用Count(1),从而可以提升性能,给出的理由是Coun

Oracle SQL性能优化

转载自:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection ta

<转>Oracle SQL性能优化

原文链接:http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html (1)      选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection t

关于SQL性能优化的十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

1.SQL优化系列-->高手详解SQL性能优化十条经验

1.查询的模糊匹配 尽量避免在一个复杂查询里面使用 LIKE '%parm1%'—— 红色标识位置的百分号会导致相关列的索引无法使用,最好不要用. 解决办法: 其实只需要对该脚本略做改进,查询速度便会提高近百倍.改进方法如下: a.修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表,用户模糊输入供应商名称时,直接在前台就帮忙定位到具体的供应商,这样在调用后台程序时,这列就可以直接用等于来关联了. b.直接修改后台——根据输入条件,先查出符合条件的供应商,并把相关记录保存在一个

Oracle SQL性能优化系列

1. 选用适合的ORACLE优化器 ORACLE的优化器共有3种: a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行an