优化SQL的执行速度

在项目开发中,页面的反应速度是非常重要的,改善页面反应速度的方法有很多。

但一般的问题多数是出现在数据库访问的SQL上面。

比如:重复多次访问数据库,SQL速度很低等。

重复多次访问数据库需要修改逻辑来减少数据库的访问。而SQL的执行速度可以通过仔细调试解决。

下面是一些SQL的性能调试方法.整理于网络内容。

1. IN和EXISTS

--1.慢  
SELECT  name  
FROM    Personnel  
WHERE   birthday IN (SELECT  birthday  
                       FROM     Celebrities);  
  
--2.快  
SELECT  P.name  
FROM    Personnel AS P  
WHERE   EXISTS   (SELECT  
                  FROM Clelebrities AS C  
                  WHERE P.birthday = C.birthday);

其中EXISTS (SELECT * FROM …)的写法比EXISTS (SELECT 列名 FROM …)的写法好。

2.  COUNT(*) 和 COUNT(列名)

COUNT(列名)较快

3. GROUP BY 使用index。

GROUP BY col1 如果不能使用index。 GROUP BY col1,col2能够使用index的话,改为 GROUP BY col1,col2。

4. ORDER BY 使用index。

和GROUP BY同理。

5. UNION、INTERSECT、EXCEPT 后面加上ALL 关键字

如果对重复数据不是很敏感的时候,在UNION、INTERSECT、EXCEPT 后面加上ALL 关键字后,性能会得到提升。

6. 下面的一些写法也会造成使用了index。

/* 1.index的col_1列有运算 */  
SELECT *   
  FROM SomeTable  
 WHERE col_1 * 1.1 > 100;

    这种情况改为 WHERE col_1  > 100/1.1即可。

    1. WHERE  col_1 IS NULL;

    使用了is null的时候也是使用不了index的。这个时候可以做个函数index来解决。

    1. WHERE  SUBSTR(col_1, 1, 1) = ‘a‘;

    index的列使用了函数。这个时候可以做个函数index来解决。

    1. WHERE  col_1 <> 100;

    使用了否定形式。 (<>, !=,NOT EQUAL, NOT IN)也是一样的。

    比如通过 col_1 < 100 OR col_1 > 100这种变换的形式来解决。

    1. WHERE  col_1 > 100  OR col_2 = ‘abc‘;

    OR的时候最好改为in。 如果非要使用OR的话,追加bitmap index。

    &times; SELECT  *   FROM  SomeTable  WHERE  col_1  LIKE ‘%a‘;  
    &times; SELECT  *   FROM  SomeTable  WHERE  col_1  LIKE ‘%a%‘;  
    ○ SELECT  *   FROM  SomeTable  WHERE  col_1  LIKE ‘a%‘;

      Like的时候,只有前方一致能够使用index。

      后方一致可以通过REVERSE转换后,改为前方一致就可以了。部分一致可以写个函数,追加函数index就可以了。

      SELECT * FROM SomeTable WHERE col_1 = 10;  
      SELECT * FROM SomeTable WHERE col_1 = ‘10‘;  
      SELECT * FROM SomeTable WHERE col_1 = CAST(10, AS CHAR(2));

      col_1为char类型,类型不匹配的时候,不能使用index。改为类型一致。

      ○ SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 AND col_3 = 500;  
      ○ SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 ;  
      &times; SELECT * FROM SomeTable WHERE col_1 = 10 AND col_3 = 500 ;  
      &times; SELECT * FROM SomeTable WHERE col_2 = 100 AND col_3 = 500 ;  
      &times; SELECT * FROM SomeTable WHERE col_2 = 100 AND col_1 = 10 ;

        假设col_1, col_2, col_3 列上有index,如果顺序不对的话不能使用index。

        1. rowid(Oracle)、oid(PostgreSQL)如果知道行号的话,行号访问最快。
        &times; SELECT * FROM SomeTable;  
        ○ SELECT col_1, col_2, col_3 FROM SomeTable;

          最好只取需要的数据。这样可以减少零时表的大小,也能减少网络的通信量。

          优化SQL的执行速度

          时间: 2024-10-09 05:59:14

          优化SQL的执行速度的相关文章

          查看Sql语句执行速度

          原文链接:http://www.cnblogs.com/New-world/archive/2012/11/28/2793560.htmlMS_SQL模糊查询like和charindex的对比 like查询效率低下,网上搜了一下替代like查询的方法,都是说用charindex方法,自己对比了一下查询速度 test1表中有一千两百多万条数据,我只给ID加了索引 先看一下 '%我%'这种模糊查询: declare @q datetime set @q = getdate() select ID,U

          MySQL 优化sql explain执行计划详解

          mysql explain执行计划详解 1).id列数字越大越先执行,如果说数字一样大,那么就从上往下依次执行,id列为null的就表是这是一个结果集,不需要使用它来进行查询. 2).select_type列常见的有:A:simple:表示不需要union操作或者不包含子查询的简单select查询.有连接查询时,外层的查询为simple,且只有一个B:primary:一个需要union操作或者含有子查询的select,位于最外层的单位查询的select_type即为primary.且只有一个C:

          简述项目中优化sql语句执行效率的方法,从哪些方面,sql语句性能如何分析?

          (1)尽量选择较小的列: (2)将where中用的比较频繁的字段建立索引: (3)select中避免使用*: (4)避免在索引列上使用计算.not in和<>等操作: (5)当只需要一行数据时候使用limit1: (6)保证单表数据不超过200w,实时分割表: 针对查询较慢的语句,可以使用explain来分析该语句具体的执行情况.

          【知识点整理】Oracle中NOLOGGING、APPEND、ARCHIVE和PARALLEL下,REDO、UNDO和执行速度的比较

          [知识点整理]Oracle中NOLOGGING.APPEND.ARCHIVE和PARALLEL下,REDO.UNDO和执行速度的比较 1  BLOG文档结构图 2  前言部分 2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 系统和会话级别的REDO和UNDO量的查询 ② NOLOGGING.APPEND.ARCHIVE和PARALLEL下,REDO.UNDO和执行速度的比较(重点)   Tips: ① 本文

          优化sql,返回行数少情况下,NL比hash快好多

          sql如下 select t.id, t.value, tt.sort as sortno from ENGINEERING_TYPE t left join ENGINEERING_TYPE tt on t.parentid = tt.id where t.delete_flag = 0 and t.hasson = 0 order by sortno, t.sort sql很简单,相当于自连接 ,返回行数12行,非常小,但是运行5s左右才出结果 看一下执行计划 可以看到,表与表之间走了has

          mysql优化sql语句

          mysql优化sql语句 常见误区 www.2cto.com 误区1: count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好, 其实这是一个误区.对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化. 误区2: count(column) 和 count(*) 是一样的 这个误区甚至在很多

          SQL Server 并行操作优化,避免并行操作被抑制而影响SQL的执行效率

          为什么我也要说SQL Server的并行: 这几天园子里写关于SQL Server并行的文章很多,不管怎么样,都让人对并行操作有了更深刻的认识. 我想说的是:尽管并行操作可能(并不是一定)存在这样或者那样的问题,但是我们不能否认并行,仍然要利用好并行. 但是,实际开发中,某些SQL语句的写法会导致用不到并行,从而影响到SQL的执行效率 所以,本文要表达的是:我们要利用好并行,不要让一些SQL的写法问题“抑制”了并行,让我们享受不了并行带来的快感 关于SQL Server的并行: 所谓的并行,指S

          SQL Server SQL性能优化之--通过拆分SQL提高执行效率,以及性能高低背后的原因

          复杂SQL拆分优化 拆分SQL是性能优化一种非常有效的方法之一, 具体就是将复杂的SQL按照一定的逻辑逐步分解成简单的SQL,借助临时表,最后执行一个等价的逻辑,已达到高效执行的目的 一直想写一遍通过拆分SQL来优化的博文,最近刚好遇到一个实际案例,比较有代表性,现分享出来, 我们来通过一个案例来分析,为什么拆分语句可以提高SQL执行效率,更重要的是弄清楚,拆分前为什么慢,拆分后为什么快了? 幼稚的话,各位看官莫笑 先看一下相关表的数据量,大表也有5900多万,小表有160多万 (声明:我从来没

          优化SQL执行路径提高报表性能

          报表出现性能问题需要对数据源计算进行优化时,执行路径难以确定从而被干预是阻碍报表优化的难题之一.由于数据库执行路径对开发人员不透明,报表优化需要指定执行路径时,程序员会很难甚至无法干预.而一般报表工具不具备强计算能力,大部分计算仍然要依靠数据库进行,这就导致很多报表优化效果不理想. 不同于一般报表工具,润乾集算报表内置了专门用于数据计算的集算引擎,开发人员可以通过编写集算脚本完成报表数据源准备.与数据库执行SQL路径不可控相比,集算脚本的执行过程是可控的,开发人员可根据实际情况编写或更改计算执行