乾貨!SQL性能優化,書寫高質量SQL語句

NO IMAGE

寫SQL語句的時候我們往往關注的是SQL的執行結果,但是是否真的關注了SQL的執行效率,是否注意了SQL的寫法規範?

以下的乾貨分享是在實際開發過程中總結的,希望對大家有所幫助!

1. 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;

如果我們結合order by使用。很快,0.04秒就OK。 因為使用了id主鍵做索引!當然,是否能夠使用索引還需要根據業務邏輯來定,這裡只是為了提醒大家,在分頁的時候還需謹慎使用!

方案二

select id from A order by id  between 90000 and 90010;

2.利用limit 1 、top 1 取得一行

有些業務邏輯進行查詢操作時(特別是在根據某一字段DESC,取最大一筆).可以使用limit 1 或者 top 1 來終止[數據庫索引]繼續掃描整個表或索引。

反例

SELECT id FROM A LIKE 'abc%' 

正例

SELECT id FROM A LIKE 'abc%' limit 1

3. 任何情況都不要用 select * from table ,用具體的字段列表替換”*”,不要返回用不到的字段,避免全盤掃描!

反例

SELECT * FROM A

正例

SELECT id FROM A 

4. 批量插入優化

反例

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

正例

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

sql語句的優化主要在於對索引的正確使用,而我們在開發中經常犯的錯誤便是對錶進行全盤掃描,一來影響性能,而來耗費時間!

5.like語句的優化

反例

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

由於abc前面用了“%”,因此該查詢必然走全表查詢,除非必要(模糊查詢需要包含abc),否則不要在關鍵詞前加%

正例

SELECT id FROM A WHERE name like 'abc%'

實例

mysql版本:5.7.26

select nick_name from member where nick_name like '%小明%'

乾貨!SQL性能優化,書寫高質量SQL語句

like’%小明%’ 並未使用索引!

select nick_name from member where nick_name like '小明%'

乾貨!SQL性能優化,書寫高質量SQL語句

like’小明%’ 成功使用索引!

6.where子句使用or的優化

通常使用 union all 或 union 的方式替換“or”會得到更好的效果。where子句中使用了or關鍵字,索引將被放棄使用。

反例

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

7.where子句中使用 IS NULL 或 IS NOT NULL 的優化

反例

SELECT id FROM A WHERE num IS NULL

在where子句中使用 IS NULL 或 IS NOT NULL 判斷,索引將被放棄使用,會進行全表查詢

正例

優化成num上設置默認值0,確保表中num沒有null值, IS NULL 的用法在實際業務場景下SQL使用率極高,我們應注意避免全表掃描

SELECT id FROM A WHERE num=0

8.where子句中對字段進行表達式操作的優化

不要在where子句中的“=”左邊進行函數、算數運算或其他表達式運算,否則系統將可能無法正確使用索引。

  • 1
SELECT id FROM A WHERE datediff(day,createdate,'2019-11-30')=0 

優化為

SELECT id FROM A WHERE createdate>='2019-11-30' and createdate<'2019-12-1'
  • 2
SELECT id FROM A WHERE year(addate) <2020

優化為

SELECT id FROM A where addate<'2020-01-01'

9.排序的索引問題 

mysql查詢只是用一個索引,因此如果where子句中已經使用了索引的話,那麼order by中的列是不會使用索引。因此數據庫默認排序可以符合要求情況下不要使用排序操作;

儘量不要包含多個列的排序,如果需要最好給這些列創建複合索引

10. 儘量用 union all 替換 union

union和union all的差異主要是前者需要將兩個(或者多個)結果集合並後再進行唯一性過濾操作,這就會涉及到排序,增加大量的cpu運算,加大資源消耗及延遲。所以當我們可以確認不可能出現重複結果集或者不在乎重複結果集的時候,儘量使用union all而不是union

11.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連接

  • 第二:子查詢的性能又比外連接性能慢,儘量用外連接來替換子查詢。

反例

mysql是先對外表A執行全表查詢,然後根據uuid逐次執行子查詢,如果外層表是一個很大的表,我們可以想象查詢性能會表現比這個更加糟糕。

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

執行時間:2s左右

正例

Select* from A inner join B ON A.uuid=B.uuid where b.uuid>=3000;  這個語句執行測試不到一秒;

執行時間:1s不到

  • 第三:使用JOIN時候,應該用小的結果驅動大的結果

left join 左邊表結果儘量小,如果有條件應該放到左邊先處理,right join同理反向。如:

反例

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;

12.exist & in 優化

SELECT * from A WHERE id in ( 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表數據大的情況

相關文章

2019與子弈的前端之路(乾貨滿滿)|年度徵文

如何全面出色的回答面試官防抖與節流提問?

2020年了,12道高頻JavaScript手寫面試題及答案

JavaScript核心知識點(上篇)