SQL语句优化

时间 2019-11-10 标签 sql 语句优化

　　怎么加快查询速度，优化查询效率，主要原则就是应尽可能避免全表扫描，应该考虑在where及order by 涉及的列上创建索引。mysql

　　创建索引不是建的越多越好，原则是：sql

　　第一：一个表的索引不是越多越好，也没有一个具体的数字，根据以往的经验，一个表的索引最多不能超过6个，由于索引越多，对update和insert操做也会有性能的影响，涉及到索引的新建和重建操做。数据库

　　第二：创建索引的方法论为：缓存

多数查询常用的列；
不多进行修改操做的列；
索引须要创建在数据差别化大的列上

　　利用以上的基础咱们讨论一下如何优化sql.并发

　　一、sql语句模型结构优化指导函数

　　　　a. ORDER BY + LIMIT组合的索引优化性能

　　　　　　若是一个SQL语句形如：SELECT [column1],[column2],…. FROM [TABLE] ORDER BY [sort] LIMIT [offset],[LIMIT];测试

　　　　　　这个SQL语句优化比较简单，在[sort]这个栏位上创建索引便可。大数据

　　　　b. WHERE + ORDER BY + LIMIT组合的索引优化优化

　　　　　　若是一个SQL语句形如：SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] = [VALUE] ORDER BY [sort] LIMIT [offset],[LIMIT];

　　　　　　这个语句，若是你仍然采用第一个例子中创建索引的方法，虽然能够用到索引，可是效率不高。更高效的方法是创建一个联合索引(columnX,sort)

　　　　c. WHERE+ORDER BY多个栏位+LIMIT

　　　　　　若是一个SQL语句形如：SELECT * FROM [table] WHERE uid=1 ORDER x,y LIMIT 0,10;

　　　　　　对于这个语句，你们多是加一个这样的索引:(x,y,uid)。但实际上更好的效果是(uid,x,y)。这是由MySQL处理排序的机制形成的。

　　二、复合索引(形如(x,y,uid)索引的索引)

　　　　先看这样一条语句这样的：select* from users where area =’beijing’ and age=22;

　　　若是咱们是在area和age上分别建立索引的话，因为mysql查询每次只能使用一个索引，因此虽然这样已经相对不作索引时全表扫描提升了不少效率，可是若是area，age两列上建立复合索引的话将带来更高的效率。

　　在使用索引字段做为条件时，若是该索引是复合索引，那么必须使用到该索引中的第一个字段做为条件时才能保证系统使用该索引，不然该索引将不会被使用，而且应尽量的让字段顺序与索引顺序相一致。

　　　例如咱们创建了一个这样的索引（area,age,salary），那么其实至关于建立了（area,age,salary）,(area,age),(area)三个索引，这样称为最佳左前缀特性。

　　三、like语句优化

SELECT id FROM A WHERE name like '%abc%'

　　因为abc前面用了“%”，所以该查询必然走全表查询，除非必要，不然不要在关键词前加%，优化成以下

SELECT id FROM A WHERE name like 'abc%'

　　四、where子句使用！= 或 <> 操做符优化

　　在where子句中使用！= 或 <>操做符，索引将被放弃使用，会进行全表查询。

　　如SQL:SELECT id FROM A WHERE ID != 5 优化成：SELECT id FROM A WHERE ID>5 OR ID<5

　　五、where子句中使用 IS NULL 或 IS NOT NULL 的优化

　　在where子句中使用 IS NULL 或 IS NOT NULL 判断，索引将被放弃使用，会进行全表查询。

　　如SQL:SELECT id FROM A WHERE num IS NULL 优化成num上设置默认值0，确保表中num没有null值，而后SQL为：SELECT id FROM A WHERE num=0

　　六、where子句使用or的优化

　　不少时候使用union all 或 nuin(必要的时候)的方式替换“or”会获得更好的效果。where子句中使用了or,索引将被放弃使用。

　　如SQL:SELECT id FROM A WHERE num =10 or num = 20 优化成：SELECT id FROM A WHERE num = 10 union all SELECT id FROM A WHERE num=20

　　七、where子句使用IN 或 NOT IN的优化

　　in和not in 也要慎用，不然也会致使全表扫描。

　　方案一：between替换in

　　如SQL:SELECT id FROM A WHERE num in(1,2,3) 优化成：SELECT id FROM A WHERE num between 1 and 3

　　方案二：exist替换in

　　如SQL:SELECT id FROM A WHERE num in(select num from b ) 优化成：SELECT num FROM A WHERE num exists(select 1 from B where B.num = A.num)

　　方案三：left join替换in

　　如SQL:SELECT id FROM A WHERE num in(select num from B) 优化成：SELECT id FROM A LEFT JOIN B ON A.num = B.num

　　八、where子句中对字段进行表达式操做的优化

　　不要在where子句中的“=”左边进行函数、算数运算或其余表达式运算，不然系统将可能没法正确使用索引。

　　如SQL:SELECT id FROM A WHERE num/2 = 100 优化成：SELECT id FROM A WHERE num = 100*2

　　如SQL:SELECT id FROM A WHERE substring(name,1,3) = 'abc' 优化成：SELECT id FROM A WHERE LIKE 'abc%'

　　如SQL:SELECT id FROM A WHERE datediff(day,createdate,'2016-11-30')=0 优化成：SELECT id FROM A WHERE createdate>='2016-11-30' and createdate<'2016-12-1'

　　如SQL:SELECT id FROM A WHERE year(addate) <2016 优化成：SELECT id FROM A where addate<'2016-01-01'

　　九、任何地方都不要用 select * from table ，用具体的字段列表替换"*"，不要返回用不到的字段　　

　　十、使用“临时表”暂存中间结果

　　　　采用临时表暂存中间结果好处：

　　　　　　（1）避免程序中屡次扫描主表，减小程序执行“共享锁”阻塞“更新锁”，减小了阻塞，提升了并发性能。

　　　　　　（2）尽可能使用表变量来代替临时表。若是表变量包含大量数据，请注意索引很是有限（只有主键索引）。

　　　　　　（3）避免频繁建立和删除临时表，以减小系统资源的浪费。

　　　　　　（4）尽可能避免向客户端返回大数据量，若数据量过大，应考虑相应需求是否合理。

　　十一、limit分页优化

　　　　当偏移量特别时，limit效率会很是低

　　　　SELECT id FROM A LIMIT 1000,10 很快

　　　　SELECT id FROM A LIMIT 90000,10 很慢

　　　　优化方法：

　　　　方法一：select id from A order by id limit 90000,10; 很快，0.04秒就OK。由于用了id主键作索引固然快

　　　　方法二：select id,title from A where id>=(select id from collect order by id limit 90000,1) limit 10;

　　 方法三：select id from A order by id between 10000000 and 10000010;

　　十二、批量插入优化

INSERT into person(name,age) values('A',14)
INSERT into person(name,age) values('B',14)
INSERT into person(name,age) values('C',14)

　　　　可优化为：

INSERT into person(name,age) values('A',14),('B',14),('C',14),

　　1三、利用limit 1 、top 1 取得一行

　　　　有时要查询一张表时，你知道只须要看一条记录，你可能去查询一条特殊的记录。可使用limit 1 或者 top 1 来终止数据库索引继续扫描整个表或索引。

　　　　如SQL：SELECT id FROM A LIKE 'abc%' 优化为：SELECT id FROM A LIKE 'abc%' limit 1

　　1四、尽可能不要使用 BY RAND()命令

　　　　BY RAND()是随机显示结果，这个函数可能会为表中每个独立的行执行BY RAND()命令，这个会消耗处理器的处理能力。

　　　　如SQL：SELECT * FROM A order by rand() limit 10 优化为：SELECT * FROM A WHERE id >= ((SELECT MAX(id) FROM A)-(SELECT MIN(id) FROM A)) * RAND() + (SELECT MIN(id) FROM A) LIMIT 10

　　1五、排序的索引问题　

　　　Mysql查询只是用一个索引，所以若是where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。所以数据库默认排序能够符合要求状况下不要使用排序操做；

　　　尽可能不要包含多个列的排序，若是须要最好给这些列建立复合索引。

　　1六、尽可能用 union add 替换 union

　　　union和union all的差别主要是前者须要将两个（或者多个）结果集合并后再进行惟一性过滤操做，这就会涉及到排序，增长大量的cpu运算，加大资源消耗及延迟。因此当咱们能够确认不可能出现重复结果集或者不在意重复结果集的时候，尽可能使用union all而不是union

　　1七、避免类型转换

　　　这里所说的“类型转换”是指where子句中出现column字段的类型和传入的参数类型不一致的时候发生的类型转换。人为的上经过转换函数进行转换，直接致使mysql没法使用索引。若是非要转型，应该在传入参数上进行转换。

　例如utime 是datetime类型，传入的参数是“2016-07-23”，在比较大小时一般是 date（utime）>"2016-07-23",能够优化为utime>"2016-07-23 00：00：00"

　　1八、尽量使用更小的字段　　　　　　　　

　　　　MySQL从磁盘读取数据后是存储到内存中的，而后使用cpu周期和磁盘I/O读取它，这意味着越小的数据类型占用的空间越小，从磁盘读或打包到内存的效率都更好，但也不要太过执着减少数据类型，要是之后应用程序发生什么变化就没有空间了。

　　　　修改表将须要重构，间接地可能引发代码的改变，这是很头疼的问题，所以须要找到一个平衡点。

　　1九、Inner join 和 left join、right join、子查询

　　第一：inner join内链接也叫等值链接是，left/rightjoin是外链接。

　　　　 SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;

　　　　 SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;

　　　　 SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;

　　　　通过来之多方面的证明inner join性能比较快，由于inner join是等值链接，或许返回的行数比较少。可是咱们要记得有些语句隐形的用到了等值链接，如：

　　　　SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;

　　　　推荐：能用inner join链接尽可能使用inner join链接

　　 第二：子查询的性能又比外链接性能慢，尽可能用外链接来替换子查询。

　　　　Select* from A where exists (select * from B where id>=3000 and A.uuid=B.uuid);

　　　　A表的数据为十万级表，B表为百万级表，在本机执行差很少用2秒左右，咱们能够经过explain能够查看到子查询是一个相关子查询(DEPENDENCE SUBQUERY);Mysql是先对外表A执行全表查询，而后根据uuid逐次执行子查询，若是外层表是一个很大的表，咱们能够想象查询性能会表现比这个更加糟糕。

　　一种简单的优化就是用innerjoin的方法来代替子查询，查询语句改成：

　　　Select* from A inner join B ON A.uuid=B.uuid using(uuid) where b.uuid>=3000; 这个语句执行测试不到一秒；

　　第三：使用JOIN时候，应该用小的结果驱动打的结果（left join 左边表结果尽可能小，若是有条件应该放到左边先处理，right join同理反向），同时尽可能把牵涉到多表联合的查询拆分多个query (多个表查询效率低，容易锁表和阻塞)。如：

　　Select * from A left join B A.id=B.ref_id where A.id>10;能够优化为：select * from (select * from A wehre id >10) T1 left join B on T1.id=B.ref_id;

　　20、exist 代替 in

SELECT * from A WHERE idin (SELECT id from B)

SELECT * from A WHERE id EXISTS(SELECT 1 from A.id= B.id)

　　in 是在内存中遍历比较

　　exist 须要查询数据库，因此当B的数据量比较大时，exists效率优于in.

　　in()只执行一次，把B表中的全部id字段缓存起来，以后检查A表的id是否与B表中的id相等，若是id相等则将A表的记录加入到结果集中，直到遍历完A表的全部记录。

　　In 操做的流程原理如同一下代码

    List resultSet={};

    Array A=(select * from A);
    Array B=(select id from B);

    for(int i=0;i<A.length;i++) {
            for(int j=0;j<B.length;j++) {
          if(A[i].id==B[j].id) {
             resultSet.add(A[i]);
             break;
          }
       }
    }
    return resultSet;

　　能够看出，当B表数据较大时不适合使用in()，由于它会B表数据所有遍历一次

　　如：A表有10000条记录，B表有1000000条记录，那么最多有可能遍历10000*1000000次，效率不好。

　　再如：A表有10000条记录，B表有100条记录，那么最多有可能遍历10000*100次，遍历次数大大减小，效率大大提高。

　　结论：in()适合B表比A表数据小的状况

　　exist()会执行A.length()次，执行过程代码以下

    List resultSet={};
    Array A=(select * from A);
    for(int i=0;i<A.length;i++) {
       if(exists(A[i].id) {  //执行select 1 from B where B.id=A.id是否有记录返回
           resultSet.add(A[i]);
       }
    }
    return resultSet;

　　当B表比A表数据大时适合使用exists()，由于它没有那么多遍历操做，只须要再执行一次查询就行。

　　如：A表有10000条记录，B表有1000000条记录，那么exists()会执行10000次去判断A表中的id是否与B表中的id相等。

　　如：A表有10000条记录，B表有100000000条记录，那么exists()仍是执行10000次，由于它只执行A.length次，可见B表数据越多，越适合exists()发挥效果。

　　再如：A表有10000条记录，B表有100条记录，那么exists()仍是执行10000次，还不如使用in()遍历10000*100次，由于in()是在内存里遍历比较，而exists()须要查询数据库，

　　咱们都知道查询数据库所消耗的性能更高，而内存比较很快。

　　结论：exists()适合B表比A表数据大的状况

　　 当A表数据与B表数据同样大时，in与exists效率差很少，可任选一个使用。