SQL语句优化汇总(上) 感动啊 学习 收藏了

原文地址:http://topic.csdn.net/u/20080716/11/2317d040-48e7-42da-822e-040b4c55b46d.html

MS   SQL   Server查询优化方法
查询速度慢的原因很多,常见如下几种

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

可以通过如下方法来优化查询

1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。数据量(尺寸)越大,提高I/O越重要. 
        2、纵向、横向分割表,减少表的尺寸(sp_spaceuse) 
        3、升级硬件 
        4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段 
        5、提高网速; 
        6、扩大服务器的内存,Windows   2000和SQL   server   2000能支持4-8G的内存。配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。运行   Microsoft   SQL   Server?   2000   时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的   1.5   倍。如果另外安装了全文检索功能,并打算运行   Microsoft   搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的   3   倍。将   SQL   Server   max   server   memory   服务器配置选项配置为物理内存的   1.5   倍(虚拟内存大小设置的一半)。 
        7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成多个任务,就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP   BY字句同时执行,SQL   SERVER根据系统的负载情况决定最优的并行等级,复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT, DELETE还不能并行处理。 
        8、如果是使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。   like   ‘a%‘   使用索引   like   ‘%a‘   不使用索引用   like   ‘%a%‘   查询时,查询耗时和字段值总长度成正比,所以不能用CHAR类型,而是VARCHAR。对于字段的值很长的建全文索引。 
        9、DB   Server   和APPLication   Server   分离;OLTP和OLAP分离 
        10、分布式分区视图可用于实现数据库服务器联合体。联合体是一组分开管理的服务器,但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器,以支持大型的多层   Web   站点的处理需要。有关更多信息,参见设计联合数据库服务器。(参照SQL帮助文件‘分区视图‘)

a、在实现分区视图之前,必须先水平分区表 
        b、在创建成员表后,在每个成员服务器上定义一个分布式分区视图,并且每个视图具有相同的名称。这样,引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样,但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。

11、重建索引   DBCC   REINDEX   ,DBCC   INDEXDEFRAG,收缩数据和日志   DBCC   SHRINKDB,DBCC   SHRINKFILE.   设置自动收缩日志.对于大的数据库不要设置数据库自动增长,它会降低服务器的性能。   在T-sql的写法上有很大的讲究,下面列出常见的要点:首先,DBMS处理查询计划的过程是这样的:

1、   查询语句的词法、语法检查          
        2、   将语句提交给DBMS的查询优化器 
        3、   优化器做代数优化和存取路径的优化 
        4、   由预编译模块生成查询规划 
        5、   然后在合适的时间提交给系统处理执行 
        6、   最后将执行结果返回给用户其次,看一下SQL   SERVER的数据存放的结构:一个页面的大小为8K(8060)字节,8个页面为一个盘区,按照B树存放。

12、Commit和rollback的区别   Rollback:回滚所有的事物。   Commit:提交当前的事物.   没有必要在动态SQL里写事物,如果要写请写在外面如:   begin   tran   exec(@s)   commit   trans   或者将动态SQL   写成函数或者存储过程。

13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。如果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重。

14、SQL的注释申明对执行没有任何影响

15、尽可能不使用光标,它占用大量的资源。如果需要row-by-row地执行,尽量采用非光标技术,如:在客户端循环,用临时表,Table变量,用子查询,用Case语句等等。游标可以按照它所支持的提取选项进行分类:   只进   必须按照从第一行到最后一行的顺序提取行。FETCH   NEXT   是唯一允许的提取操作,也是默认方式。可滚动性   可以在游标中任何地方随机提取任意行。游标的技术在SQL2000下变得功能很强大,他的目的是支持循环。

有四个并发选项

READ_ONLY:不允许通过游标定位更新(Update),且在组成结果集的行中没有锁。

OPTIMISTIC   WITH   valueS:乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形,即在打开游标及更新行的间隔中,只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时,没有锁控制其中的行,这将有助于最大化其处理能力。如果用户试图修改某一行,则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变,则服务器就会知道其他人已更新了此行,并会返回一个错误。如果值是一样的,服务器就执行修改。   选择这个并发选项 OPTIMISTIC   WITH   ROW   VERSIONING:此乐观并发控制选项基于行版本控制。使用行版本控制,其中的表必须具有某种版本标识符,服务器可用它来确定该行在读入游标后是否有所更改。 
        在   SQL   Server   中,这个性能由   timestamp   数据类型提供,它是一个二进制数字,表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值:@@DBTS。每次以任何方式更改带有   timestamp   列的行时,SQL   Server   先在时间戳列中存储当前的   @@DBTS   值,然后增加   @@DBTS   的值。如果某   个表具有   timestamp   列,则时间戳会被记到行级。服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值,从而确定该行是否已更新。服务器不必比较所有列的值,只需比较   timestamp   列即可。如果应用程序对没有   timestamp   列的表要求基于行版本控制的乐观并发,则游标默认为基于数值的乐观并发控制。 
        SCROLL   LOCKS   这个选项实现悲观并发控制。在悲观并发控制中,在把数据库的行读入游标结果集时,应用程序将试图锁定数据库行。在使用服务器游标时,将行读入游标时会在其上放置一个更新锁。如果在事务内打开游标,则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行时,将除去游标锁。如果在事务外打开游标,则提取下一行时,锁就被丢弃。因此,每当用户需要完全的悲观并发控制时,游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁,从而阻止其它任务更新该行。 
        然而,更新锁并不阻止共享锁,所以它不会阻止其它任务读取行,除非第二个任务也在要求带更新锁的读取。滚动锁根据在游标定义的   SELECT   语句中指定的锁提示,这些游标并发选项可以生成滚动锁。滚动锁在提取时在每行上获取,并保持到下次提取或者游标关闭,以先发生者为准。下次提取时,服务器为新提取中的行获取滚动锁,并释放上次提取中行的滚动锁。滚动锁独立于事务锁,并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的选项为关,则   COMMIT   语句并不关闭任何打开的游标,而且滚动锁被保留到提交之后,以维护对所提取数据的隔离。所获取滚动锁的类型取决于游标并发选项和游标   SELECT   语句中的锁提示。 
        锁提示   只读   乐观数值   乐观行版本控制   锁定无提示   未锁定   未锁定   未锁定   更新   NOLOCK   未锁定   未锁定  未锁定   未锁定   HOLDLOCK   共享   共享   共享   更新   UPDLOCK   错误   更新   更新   更新   TABLOCKX   错误   未锁定   未锁定   更新其它   未锁定   未锁定   未锁定   更新   *指定   NOLOCK   提示将使指定了该提示的表在游标内是只读的。

16、用Profiler来跟踪查询,得到查询所需的时间,找出SQL的问题所在;用索引优化器优化索引

17、注意UNion和UNion   all   的区别。UNION   all好

18、注意使用DISTINCT,在没有必要时不要用,它同UNION一样会使查询变慢。重复的记录在查询里是没有问题的

19、查询时不要返回不需要的行、列

20、用sp_configure   ‘query   governor   cost   limit‘或者SET   QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的资源超出限制时,服务器自动取消查询,在查询之前就扼杀掉。 SET   LOCKTIME设置锁的时间

时间: 2024-08-04 13:24:21

SQL语句优化汇总(上) 感动啊 学习 收藏了的相关文章

数据库性能优化之SQL语句优化(上)

一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就成为目前系统需要解决的最主要的问题之一. 系统优化中一个很重要的方面就是SQL语句的优化.对于海量数据,劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍,可见对于一个系统不是简单地能实现其功能就可,而是要写出高质量的SQL语句,提高系统的可用性. 在多数情况下,Oracle使用索

SQL语句优化技术分析

摘自  http://www.cnblogs.com/wxj1020/archive/2008/04/27/1173638.html 最近几周一直在进行数据库培训,老师精湛的技术和生动的讲解使我受益匪浅.为了让更多的新手受益,我抽空把SQL语句优化部分进行了整理,希望大家一起进步. 一.操作符优化 1.IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格.但是用IN的SQL性能总是比较低的,从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以

MySQL之SQL语句优化

一 SQL语句优化的一般步骤: 1 通过show status命令了解各种SQL语句的执行频率 mysql> show status;                #show status:显示服务器状态信息 +-----------------------------------------------+-------------+ | Variable_name                                 | Value       | +---------------

Oracle SQL语句优化34条

非常好用的SQL语句优化34条 1)选择最有效率的表名顺序(只在基于规则的优化器中有效): ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基 础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. (2) WHERE子句中的连接顺序.: ORACL

Oracle Sql语句优化

1.最高效的删除重复记录方法 (因为使用了ROWID)   例子:  DELETE FROM  EMP E  WHERE  E.ROWID > (SELECT MIN(X.ROWID) FROM  EMP X  WHERE  X.EMP_NO = E.EMP_NO); 2.在含有子查询的 SQL 语句中 , 要特别注意减少对表的查询   例子:  SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = (SELECT TAB_NAME,DB_V

Oracle大数据SQL语句优化

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, 如: select id from t where num is null    可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则

SQL语句优化系列一

SQL语句优化 1.SELECT 子句中避免使用'* ' 2.使用表的别名 (Alias) 当在 SQL 语句中连接多个表时 , 请使用表的别名并把别名前缀于每个 Column 上.这样一来,就可以减少解析的时间并减少那些由 Column 歧义引起的语法错误. 3.用 >= 替代 > 高效 : SELECT * FROM  EMP  WHERE  DEPTNO >=4 低效 : SELECT * FROM EMP WHERE DEPTNO >3 两者的区别在于,前者 DBMS 将直

mysql索引优化和sql语句优化

一.mysql索引分为btree索引和hash索引. btree索引是二叉树结构 先到索引树上找,再去根据索引到数据里边找数据. hash索引是memory引擎,精准查询非常快,如果查范围内(where>8),会比较慢.因为是无序的,无法使用前缀索引. 2.btree索引 建立索引,通常是经常用到做查询条件,做分组,做排序. 独立索引,单个建索引只能用一个索引,通常用联合索引. 如建了一个(a,b,c)的复合索引,那么实际等于建了(a),(a,b),(a,b,c)三个索引,因为每多一个索引,都会

sql语句优化方案

怎么加快查询速度,优化查询效率,主要原则就是应尽量避免全表扫描,应该考虑在where及order by 涉及的列上建立索引. 建立索引不是建的越多越好,原则是: 第一:一个表的索引不是越多越好,也没有一个具体的数字,根据以往的经验,一个表的索引最多不能超过6个,因为索引越多,对update和insert操作也会有性能的影响,涉及到索引的新建和重建操作. 第二:建立索引的方法论为: 1.多数查询经常使用的列:2.很少进行修改操作的列:3.索引需要建立在数据差异化大的列上 利用以上的基础我们讨论一下