人工智能自动sql优化工具--SQLTuning for SQL Server

针对这种情况,人工智能自动SQL优化工具应运而生。现在我就向大家介绍这样一款工具:SQLTuning for SQL Server。

1. SQL Tuning 简介

SQL Turning是Quest公司出品的Quest Central软件中的一个工具。

QuestCentral(图1)是一款集成化、图形化、跨平台的数据库管理解决方案,可以同时管理Oracle、DB2 和 SQL server 数据库。它包含了如下的多个工具:

数据库管理(DBA)
 数据库监控(Monitoring Pack)
 数据库诊断 (Spotlight Diagnostics)
 数据库分析 (Database Analysis)
 SQL优化 (SQL Tuning)
 空间管理 (Space Management)
 压力测试 (Load Generator)
 数据生成 (Data Generator)
 PL/SQL 开发 (TOAD)
 专家建议 (Knowledge Expert)

今天,我们只介绍其中的SQL优化(SQL Tuning for SQL Server) 的使用方法。

图1 quest central界面

2. 使用SQL Tuning 优化SQL

下面我们用SQLServer自带的Northwind数据库为例,帮助大家了解如何使用SQLTuning优化SQL。

(1)建立连接。
在QuestCentral主界面上的“Database”树上选择“SQLServer”,然后在下方出现的“Tools”框中选择“SQLTuning”选项,打开“Lanch SQL Tuning for SQL ServerConnections”对话框(图2)。我们在这里建立数据库服务器的连接,以后的分析工作都会在它上面完成。

图2 “建立连接”对话框

双击“NewConnection”图标,在弹出窗口中输入数据库的信息,单击“OK”,然后单击“Connect”即可。

(2)分析原始SQL语句 。
在打开窗口的“OriangalSQL”文本框内输入需要分析的原始SQL语句,代码如下:

/*查询卖出价个不同的同一货物名称*/
select DISTINCT c.CompanyName,p.ProductName
from [Order Details] od1,[Order Details] od2 , Orders o1 , Orderso2,Customers c, Products p
where od1.UnitPrice<>od2.UnitPrice andod1.ProductID=od2.ProductID
and od1.OrderID=o1.OrderID
and od2.OrderID=o2.OrderID
and o1.CustomerID=o2.CustomerID
and o1.CustomerID=C.CustomerID

首先在界面左上方选择数据库,然后点击工具栏上的“Execute”按钮,执行原始的SQL语句,SQLTuning会自动分析SQL的执行计划,并把分析结果显示到界面上(图3)。

图3 分析原始SQL语句

(3)优化SQL。

现在我们点击工具栏上的“Optimize Statement”按钮,让SQLTuning开始优化SQL,完成后,可以看到SQLTuning产生了34条与原始SQL等价的优化方案(图4)。

图4 SQL优化方案

(4)获得最优SQL。

接下来,我们来执行上面产生的优化方案,以选出性能最佳的等效SQL语句。在列表中选择需要执行的优化方案(默认已全部选中),然后点击工具栏上的“Execute”按钮旁边的下拉菜单,选择“ExecuteSelected”。等到所有SQL运行完成后,点击界面左方的“TuningResolution”按钮,可以看到最优的SQL已经出来啦,运行时间竟然可以提高52%!(图5)

图5 “Tuning Resolution”界面

(5)学习书写专家级的SQL语句。

通过上面的步骤,我们已经可以实现自动优化SQL语句,但更重要的是,我们还可以学习如何书写这样高性能的SQL语句。点击界面左方的“CompareScenarios”按钮,我们可以比较优化方案和原始SQL中的任意2条SQL语句,SQLTuning会将它们之间的不同之处以不同颜色表示出来,还可以在下方的“执行计划”中,通过比较两条SQL语句的执行计划的不同,来了解其中的差异(图6)。

图6 “Compare Scenarios”界面

3.小结

SQLTuning等人工智能自动SQL优化工具的出现,为我们节省出大量的时间和精力。借助这些工具的帮助,书写专家级的SQL语句将不再是难事。

(0)

相关推荐

  • SQL SERVER 的SQL语句优化方式小结

    1.SQL SERVER 2005的性能工具中有SQL Server Profiler和数据库引擎优化顾问,极好的东东,必须熟练使用. 2.查询SQL语句时打开"显示估计的执行计划",分析每个步骤的情况 3.初级做法,在CPU占用率高的时候,打开SQL Server Profiler运行,将跑下来的数据存到文件中,然后打开数据库引擎优化顾问调用那个文件进行分析,由SQL SERVER提供索引优化建议.采纳它的INDEX索引优化部分. 4.但上面的做法经常不会跑出你所需要的,在最近的优化

  • SQLServer 优化SQL语句 in 和not in的替代方案

    但是用IN的SQL性能总是比较低的,从SQL执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别: SQL试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询.由此可见用IN的SQL至少多了一个转换的过程.一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了. 推荐在业务密集的SQL当中尽量不采用IN操作符 NOT IN 此操作是强列推荐不使用的,因为它不能应用表的索引.推荐用NOT EXIS

  • sql语句优化之SQL Server(详细整理)

    MS SQL Server查询优化方法 查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,

  • SQL Server 2016 查询存储性能优化小结

    作为一个DBA,排除SQL Server问题是我们的职责之一,每个月都有很多人给我们带来各种不能解释却要解决的性能问题. 我就多次听到,以前的SQL Server的性能问题都还好且在正常范围内,但现在一切已经改变,SQL Server开始糟糕, 疯狂的事情不能解释.在这个情况下我介入,分析下整个SQL Server的安装,最后用一些神奇的调查方法找出性能问题的根源. 但很多时候问题的根源是一样的:所谓的计划回归(Plan Regression),即特定查询的执行计划已经改变.昨天SQL Serv

  • win2008 r2 服务器php+mysql+sqlserver2008运行环境配置(从安装、优化、安全等)

    win2008 r2 安装 http://www.jb51.net/article/38048.htm iis的安装 http://www.jb51.net/article/86390.htm php的安装注意事项: 下载非安全线程 版本 nts php 5.2.17 http://www.jb51.net/softs/268745.html 其它版本可以到 http://museum.php.net/php5/里面很多经典的老版本. PHP 5.5 (5.5.36) VC11 x64 Non

  • SQL SERVER性能优化综述(很好的总结,不要错过哦)第1/3页

    一.分析阶段 一般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性.可用性.可靠性.安全性需求往往吸引了我们大部分的注意力,但是,我们必须注意,性能是很重要的非功能性需求,必须根据系统的特点确定其实时性需求.响应时间的需求.硬件的配置等.最好能有各种需求的量化的指标. 另一方面,在分析阶段应该根据各种需求区分出系统的类型,大的方面,区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统). 二.设计阶段 设计阶段可以说是以后系统性能的关键阶段,在这个阶段,有一个关系到以后几乎

  • 谈谈Tempdb对SQL Server性能优化有何影响

    先给大家巩固tempdb的基础知识 简介: tempdb是SQLServer的系统数据库一直都是SQLServer的重要组成部分,用来存储临时对象.可以简单理解tempdb是SQLServer的速写板.应用程序与数据库都可以使用tempdb作为临时的数据存储区.一个实例的所有用户都共享一个Tempdb.很明显,这样的设计不是很好.当多个应用程序的数据库部署在同一台服务器上的时候,应用程序共享tempdb,如果开发人员不注意对Tempdb的使用就会造成这些数据库相互影响从而影响应用程序. 特性:

  • SQL Server中的SQL语句优化与效率问题

    很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解.比如: select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan' 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那

  • SQL Server游标的使用/关闭/释放/优化小结

    游标是邪恶的! 在关系数据库中,我们对于查询的思考是面向集合的.而游标打破了这一规则,游标使得我们思考方式变为逐行进行.对于类C的开发人员来着,这样的思考方式会更加舒服. 正常面向集合的思维方式是: 而对于游标来说: 这也是为什么游标是邪恶的,它会使开发人员变懒,懒得去想用面向集合的查询方式实现某些功能. 同样的,在性能上,游标会吃更多的内存,减少可用的并发,占用宽带,锁定资源,当然还有更多的代码量-- 从游标对数据库的读取方式来说,不难看出游标为什么占用更多的资源,打个比方: 当你从ATM取钱

  • SQLServer性能优化--间接实现函数索引或者Hash索引

    SQLServer中没有函数索引,在某些场景下查询的时候要根据字段的某一部分做查询或者经过某种计算之后做查询,如果使用函数或者其他方式作用在字段上之后,就会限制到索引的使用,不过我们可以间接地实现类似于函数索引的功能. 另外一个就是如果查询字段较大或者字段较多的时候,所建立的索引就显得有点笨重,效率也不高,就需要考虑使用一个较小的"替代性"字段做等价替换,类似于Hash索引, 本文粗浅地介绍两种上述两种问题的解决方式,仅供参考. 1,在计算列上建索引,实现"函数索引"

随机推荐