SQL語句優化

時間  2019-11-10
標籤 sql 語句 優化 欄目 SQL 简体版
原文   原文鏈接

　　怎麼加快查詢速度，優化查詢效率，主要原則就是應儘可能避免全表掃描，應該考慮在where及order by 涉及的列上創建索引。mysql

　　創建索引不是建的越多越好，原則是：sql

　　第一：一個表的索引不是越多越好，也沒有一個具體的數字，根據以往的經驗，一個表的索引最多不能超過6個，由於索引越多，對update和insert操做也會有性能的影響，涉及到索引的新建和重建操做。數據庫

　　第二：創建索引的方法論爲：緩存

  1. 多數查詢常用的列；
  2. 不多進行修改操做的列；
  3. 索引須要創建在數據差別化大的列上

　　利用以上的基礎咱們討論一下如何優化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效率差很少，可任選一個使用。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程