五個(gè)提升SQL語(yǔ)句性能的小竅門(mén),進(jìn)一步提升查詢性能
在進(jìn)行數(shù)據(jù)庫(kù)操作時(shí),優(yōu)化SQL語(yǔ)句是提升性能和效率的關(guān)鍵步驟之一。無(wú)論是處理大規(guī)模數(shù)據(jù)還是簡(jiǎn)單的查詢,優(yōu)化SQL語(yǔ)句都可以明顯改善系統(tǒng)的響應(yīng)時(shí)間和資源利用率。
本文介紹五個(gè)實(shí)用的優(yōu)化SQL的技巧,幫助讀者更好地利用索引、避免性能瓶頸,并提高數(shù)據(jù)庫(kù)的整體性能。
1 內(nèi)連接說(shuō)明
當(dāng)涉及到多個(gè)表的連接查詢時(shí),通常使用join關(guān)鍵字。
最常用的連接方式是左連接和內(nèi)連接。
- left join:找到兩個(gè)表的交集,并包含左表中剩余的數(shù)據(jù)。
- inner join:找到兩個(gè)表的交集數(shù)據(jù)。
以下是使用inner join的示例:
select o.id,o.code,u.name
from order o
inner join user u on o.user_id = u.id
where u.status=1;
如果兩個(gè)表使用inner join關(guān)聯(lián),MySQL會(huì)自動(dòng)選擇兩個(gè)表中的小表驅(qū)動(dòng)大表,因此在性能上不會(huì)出現(xiàn)太多問(wèn)題。
以下是使用left join的示例:
select o.id,o.code,u.name
from order o
left join user u on o.user_id = u.id
where u.status=1;
如果兩個(gè)表使用left join關(guān)聯(lián),MySQL默認(rèn)使用左連接關(guān)鍵字驅(qū)動(dòng)右側(cè)的表。如果左表中存在大量數(shù)據(jù),則可能會(huì)出現(xiàn)性能問(wèn)題。
需要注意的是,在使用left join查詢時(shí),應(yīng)該將小表放在左側(cè),將大表放在右側(cè)。如果可以使用inner join,應(yīng)盡量避免使用left join。
2 限制索引的數(shù)量
眾所周知,索引可以大幅提高SQL查詢的性能,但索引的數(shù)量并不是越多越好。
因?yàn)楫?dāng)向表中添加新數(shù)據(jù)時(shí),同時(shí)需要為其創(chuàng)建索引,而索引需要額外的存儲(chǔ)空間和一定的性能消耗。
單個(gè)表中的索引數(shù)量應(yīng)盡量控制在5個(gè)以內(nèi),單個(gè)索引中的字段數(shù)量也不應(yīng)超過(guò)5個(gè)。
MySQL使用的B+樹(shù)結(jié)構(gòu)來(lái)保存索引,B+樹(shù)索引在插入、更新和刪除操作時(shí)需要進(jìn)行更新。如果索引過(guò)多,將消耗大量的額外性能。
那么,如果表中的索引過(guò)多,超過(guò)了5個(gè)怎么辦呢?
這個(gè)問(wèn)題需要辯證地看待。如果你的系統(tǒng)并發(fā)性較低,表中的數(shù)據(jù)量也不是很大,實(shí)際上可以使用超過(guò)5個(gè)的索引,只要不過(guò)度即可。
但對(duì)于一些高并發(fā)的系統(tǒng),務(wù)必遵守單個(gè)表上不超過(guò)5個(gè)索引的限制。
那么,高并發(fā)系統(tǒng)如何優(yōu)化索引的數(shù)量呢?
如果可以建立聯(lián)合索引,就不要建立單個(gè)索引,可以刪除一些無(wú)用的單個(gè)索引。
將一些查詢功能遷移到其他類型的數(shù)據(jù)庫(kù)中,比如Elastic Seach、HBase等,只需在業(yè)務(wù)表中建立少量的關(guān)鍵索引即可。
3 選擇適當(dāng)?shù)淖侄晤愋?/h3>
char表示固定長(zhǎng)度的字符串類型,該類型的字段存儲(chǔ)空間是固定的,會(huì)浪費(fèi)存儲(chǔ)空間。
alter table order
add column code char(20) NOT NULL;
varchar表示可變長(zhǎng)度的字符串類型,該類型的字段存儲(chǔ)空間會(huì)根據(jù)實(shí)際數(shù)據(jù)的長(zhǎng)度進(jìn)行調(diào)整,不會(huì)浪費(fèi)存儲(chǔ)空間。
alter table order
add column code varchar(20) NOT NULL;
如果是固定長(zhǎng)度的字段,比如用戶的手機(jī)號(hào)碼,一般是11位,可以定義為長(zhǎng)度為11字節(jié)的char類型。
但如果是企業(yè)名稱字段,如果定義為char類型,會(huì)存在問(wèn)題。
如果長(zhǎng)度定義得過(guò)長(zhǎng),例如定義為200字節(jié),而實(shí)際企業(yè)名稱只有50字節(jié),將浪費(fèi)150字節(jié)的存儲(chǔ)空間。
如果長(zhǎng)度定義得過(guò)短,例如定義為50字節(jié),而實(shí)際企業(yè)名稱有100字節(jié),將無(wú)法存儲(chǔ),并拋出異常。
因此,建議將企業(yè)名稱改為varchar類型。可變長(zhǎng)度字段的存儲(chǔ)空間較小,可以節(jié)省存儲(chǔ)空間,對(duì)于查詢來(lái)說(shuō),在相對(duì)較小的字段中搜索效率顯然更高。
選擇字段類型時(shí),應(yīng)遵循以下原則:
如果可以使用數(shù)字類型,就不要使用字符串,因?yàn)閿?shù)字類型的存儲(chǔ)空間更小,查詢效率更高。
盡量使用小型類型,例如使用bit類型存儲(chǔ)布爾值,tinyint類型存儲(chǔ)枚舉值等。
對(duì)于固定長(zhǎng)度的字段,可以使用char類型。
對(duì)于可變長(zhǎng)度的字段,可以使用varchar類型。
對(duì)于金額字段,使用decimal類型,避免精度丟失的問(wèn)題。
4 提高group by的效率
在許多業(yè)務(wù)場(chǎng)景中,需要使用group by關(guān)鍵字。它的主要功能是進(jìn)行去重和分組。
通常,與having一起使用,表示按照某些條件進(jìn)行分組,然后再過(guò)濾數(shù)據(jù)。
錯(cuò)誤示例
select user_id,user_name from order
group by user_id
having user_id <= 200;
這種寫(xiě)法性能較差。它首先根據(jù)用戶ID對(duì)所有訂單進(jìn)行分組,然后篩選出用戶ID大于或等于200的用戶。
分組是一個(gè)相對(duì)耗時(shí)的操作,為什么不在分組之前縮小數(shù)據(jù)范圍呢?
正確示例
select user_id,user_name from order
where user_id <= 200
group by user_id
使用where條件在分組之前過(guò)濾掉冗余數(shù)據(jù),這樣在分組時(shí)效率會(huì)更高。
實(shí)際上,這是一個(gè)思路,不僅僅適用于group by的優(yōu)化。在SQL語(yǔ)句執(zhí)行一些耗時(shí)操作之前,應(yīng)盡量縮小數(shù)據(jù)范圍,這樣可以提高整體SQL的性能。
5 索引優(yōu)化
在SQL優(yōu)化中,索引優(yōu)化是非常重要的內(nèi)容。
在許多情況下,使用索引和不使用索引時(shí),SQL語(yǔ)句的執(zhí)行效率會(huì)有很大差異。因此,索引優(yōu)化是SQL優(yōu)化的首選。
索引優(yōu)化的第一步是檢查SQL語(yǔ)句是否已經(jīng)使用了索引。
那么,如何檢查SQL是否使用了索引呢?
可以使用explain命令查看MySQL的執(zhí)行計(jì)劃。
explain select * from `order` where code='002';
圖片
以下是索引失效的一些常見(jiàn)原因:
- 不滿足最左前綴原則。
- 范圍索引列沒(méi)有放在最后。
- 使用了select *。
- 對(duì)索引列進(jìn)行了計(jì)算。
- 對(duì)索引列使用了函數(shù)。
- 字符串類型沒(méi)有加引號(hào)。
- 使用了like %。
- 錯(cuò)誤地使用了is null。
- 錯(cuò)誤地使用了or。
如果不是由于上述原因,就需要進(jìn)一步調(diào)查其他原因。
此外,您是否曾經(jīng)遇到過(guò)這樣的情況:明明是相同的SQL,只是輸入?yún)?shù)不同。有時(shí)候索引a生效,有時(shí)候索引b生效?
有時(shí)候MySQL會(huì)選擇錯(cuò)誤的索引。
如果有必要,可以使用force index來(lái)強(qiáng)制查詢SQL使用特定的索引。