每個(gè)后端都應(yīng)該知道的八個(gè)提升 SQL 性能的 Tips
作為一名后端程序員,可以說(shuō)天天都要跟數(shù)據(jù)庫(kù)打交道,不管使用的是 MySQL, Oracle 還是 SQL Server,毫無(wú)疑問(wèn)都逃不開(kāi) SQL,所以日常工作中對(duì)于 SQL 的性能優(yōu)化可謂說(shuō)十分重要。今天阿粉就帶大家看一下,每個(gè)后端程序員都應(yīng)該知道的十個(gè)提升查詢性能的技巧。
1.使用 Exists 代替子查詢
子查詢?cè)谌粘5墓ぷ髦胁豢杀苊庖欢〞?huì)使用到,很多時(shí)候我們的用法都是這樣的:
SELECT Id, Name
FROM Employee
WHERE DeptId In (SELECT Id
FROM Department
WHERE Name like '%Management%');
相信大家平??隙ǘ际沁@樣來(lái)使用的,其實(shí)還有一種更好的方法,如下所示:
SELECT Id, Name
FROM Employee
WHERE DeptId Exist (SELECT Id
FROM Department
WHERE Name like '%Management%');
這里我們使用 exist 關(guān)鍵字而不是 In 關(guān)鍵字,當(dāng)然如果在數(shù)據(jù)量不大的時(shí)候,兩種方式都可以,但是當(dāng)數(shù)據(jù)量很大的時(shí)候,exist 的方式會(huì)比 in 的方式效率高很多。因?yàn)?Exist 函數(shù)根據(jù)查詢結(jié)果返回一個(gè)布爾值,速度會(huì)快很多。
2.適當(dāng)?shù)氖褂?JOIN 來(lái)代替子查詢
除了上面的exist 之外在有些場(chǎng)景我們可以使用 JOIN 來(lái)替換子查詢,畢竟子查詢的效果是很差的,如下所示:
SELECT Id, Name
FROM Employee
WHERE DeptId in (SELECT Id
FROM Department
WHERE Name like '%Management%');
使用 JOIN 的方式如下:
SELECT Emp.Id, Emp.Name,Dept.DeptName
FROM Employee Emp
RIGHT JOIN Department Dept on Emp.DeptId = Dept.Id WHERE Dept.DeptName like '%Management%';
3.使用 Where 替代不必要的Having
對(duì)于 where 的使用相信大家都很擅長(zhǎng),但是對(duì)于 Having 的使用可能平時(shí)用的不多,阿粉這里只能說(shuō):用得不多,挺好的!對(duì)于 Having 我們是能不用就不用不到萬(wàn)不得已的時(shí)候不要用,說(shuō)真的阿粉工作這么多年,真沒(méi)有使用 Having 的場(chǎng)景。我們先看下面的示例:
Having 的用法
SELECT Emp.Id, Emp.Name,Dept.DeptName,Emp.Salary
FROM Employee Emp
RIGHT JOIN Department Dept on Emp.DeptId = Dept.Id
GROUP BY dept.DeptName
HAVING Emp.Salary >= 20000;
Where 的用法
SELECT Emp.Id, Emp.Name,Dept.DeptName,Emp.Salary
FROM Employee Emp
RIGHT JOIN Department Dept on Emp.DeptId = Dept.Id
WHERE Emp.Salary >= 20000;
為什么說(shuō) Having 的性能沒(méi)有 Where 高呢?那是因?yàn)?Where 是一種精確的匹配,但是 Having 是需要配合 Group By 來(lái)配合使用,只要涉及到 Group By 自然就效率高不起來(lái)了。
4.使用精確的字段類(lèi)型
有些小伙伴為了系統(tǒng)的可擴(kuò)展性或者壓根就不知道該把數(shù)據(jù)庫(kù)字段的類(lèi)型設(shè)置什么,所以就全部使用 char 或者 varchar,總覺(jué)得這樣更靈活,但是往往這個(gè)時(shí)候是對(duì)系統(tǒng)的最大隱患。
在使用時(shí)間類(lèi)型的字段的時(shí)候,就需要設(shè)置成 DateTime,不能用 varchar;在使用標(biāo)識(shí)是否刪除的時(shí)候就應(yīng)該使用 tinyint,能用 varchar 的就不要用 char;對(duì)于大字段 text 需要獨(dú)立出來(lái),這樣在查詢的時(shí)候就不會(huì)影響性能;對(duì)于能設(shè)置成唯一鍵的就需要設(shè)置成唯一鍵,因?yàn)槟阌肋h(yuǎn)無(wú)法避免程序會(huì)出現(xiàn)臟數(shù)據(jù),要在數(shù)據(jù)層保證一致性。
5.使用批處理代替循環(huán)
在插入數(shù)據(jù)的時(shí)候的,我們可以使用 values 來(lái)批量進(jìn)行插入,而不是通過(guò)循環(huán)來(lái)進(jìn)行單條數(shù)據(jù)的查詢,如下所示:
//不可取
For(Int i = 0;i <= 5; i++)
{
INSER INTO Table1(Id,Value) Values( i , 'Value' + i );
}
//推薦
INSERT INTO Table1(Id, Value)
Values(1,Value1),(2,Value2),(2,Value3),(4,Value4),(5,Value5);
不過(guò)要注意 values 后面的數(shù)量也是有限制的,所以兩者可以結(jié)合使用,具體的可以根據(jù)表字段的多少來(lái)決定分多少批來(lái)執(zhí)行。另外這里有一個(gè)注意的點(diǎn),很多系統(tǒng)都會(huì)底層做操作日志,而且很多時(shí)候可能是 SQL 級(jí)別的,那這個(gè)時(shí)候就需要注意,記錄操作日志的表的字段是有長(zhǎng)度限制的,這里整個(gè) SQL 的長(zhǎng)度是不能超過(guò)日志字段的長(zhǎng)度的。
6.使用 UNION ALL 替代 UNION
在使用聯(lián)合查詢的時(shí)候,很多時(shí)候我們會(huì)使用到 UNION ALL 或者 UNION 來(lái)聯(lián)合多個(gè)表,進(jìn)行匯總。那么 UNION ALL 和 UNION 的區(qū)別是什么呢?這兩個(gè)的區(qū)別是 UNION ALL 會(huì)返回聯(lián)合后的所有行記錄,而 UNION 是會(huì)進(jìn)行去重后返回。
比如說(shuō)我們有兩張表 teacher 和 student,里面的數(shù)據(jù)分別是下面:


這里這兩張表當(dāng)中,存在相同的一條數(shù)據(jù),就是(4, 馬六)這一條數(shù)據(jù),我們可以看看使用 UNION ALL 和 UNION 的效果。


可以看到第二次的查詢結(jié)果中已經(jīng)少了一行,說(shuō)明我們上面說(shuō)的 UNION 會(huì)去重的邏輯是存在的,而且去重是全字段都相同的時(shí)候才會(huì)被去重。
7.用精確的字段代替 *
另一個(gè)比較影響性能的點(diǎn)是使用 *,很多小伙伴為了省事,在編寫(xiě)查詢語(yǔ)句的時(shí)候,會(huì)使用 * 來(lái)代替所有的字段,其實(shí)并不是說(shuō)這種寫(xiě)法有什么問(wèn)題,只是這種寫(xiě)法有點(diǎn)不可控,使用 * 表示要查詢所有字段,當(dāng)我們的表是一個(gè)很簡(jiǎn)單的表,而且里面的字段都是一些小字段的時(shí)候,使用 * 完全是可以的。
但是如果是對(duì)于一些大表特別是有 text 這種大字段的表,或者是一些敏感數(shù)據(jù)的表,我們還使用 * 號(hào)去查詢數(shù)據(jù)的話,就會(huì)有很大的問(wèn)題了,一方面是有安全隱患,一方面還是增加磁盤(pán),內(nèi)存和網(wǎng)絡(luò)的傳輸,完全得不償失。
8.給必要的字段增加索引
索引作為數(shù)據(jù)庫(kù)里面一個(gè)很重要的內(nèi)容,相比大家都不陌生,給必要的字段加上索引也是很有必要的,除了主鍵索引,我們還可以添加聚簇索引和唯一索引。
總結(jié)
后端程序員除了跟服務(wù)器打交道之外最多的就是跟數(shù)據(jù)庫(kù)打交道了,如何在數(shù)據(jù)庫(kù)層面提效也是一個(gè)長(zhǎng)久的話題,這也是為什么數(shù)據(jù)庫(kù)能得到發(fā)展的原因,從關(guān)系型數(shù)據(jù)庫(kù)到 NoSQL 數(shù)據(jù)庫(kù),從 MySQL 到 ClickHouse,數(shù)據(jù)庫(kù)行業(yè)也在長(zhǎng)久的發(fā)展。















 
 
 










 
 
 
 