對(duì)于數(shù)據(jù)庫(kù)而言，只要做好數(shù)據(jù)存儲(chǔ)工作就行了，但對(duì)于SQL而言，執(zhí)行效率是很重要的指標(biāo)。目前主流的關(guān)系型數(shù)據(jù)庫(kù)都自帶了查詢分析器和優(yōu)化器，能自動(dòng)對(duì)我們編寫(xiě)的SQL進(jìn)行最優(yōu)處理，即便如此，SQL執(zhí)行慢的現(xiàn)象還是不可避免的。雖說(shuō)SQL語(yǔ)句執(zhí)行慢是大家經(jīng)常遇到的，但背后原因并不簡(jiǎn)單。

SQL執(zhí)行是偶爾慢還是一直慢？

這一點(diǎn)很重要，SQL語(yǔ)句執(zhí)行速度偶爾慢和一直慢的背后因素是不同的，自然要分場(chǎng)景來(lái)分析問(wèn)題。

SQL執(zhí)行偶爾慢的原因分析

如果一條SQL語(yǔ)句絕大多數(shù)情況下都是正常的，偶爾出現(xiàn)慢的情況，那一般來(lái)說(shuō)此SQL語(yǔ)句問(wèn)題不大，可能是其它因素影響了它的執(zhí)行效率，比如：

1、服務(wù)器內(nèi)存不足

若查詢量大，而查詢的數(shù)據(jù)頁(yè)又不在內(nèi)存中時(shí)，就需要申請(qǐng)內(nèi)存，此時(shí)一旦內(nèi)存不足就會(huì)淘汰一些內(nèi)存數(shù)據(jù)，這些操作就會(huì)影響SQL執(zhí)行速度。

2、日志文件過(guò)大

數(shù)據(jù)庫(kù)在同步日志及數(shù)據(jù)到磁盤(pán)上時(shí)，也會(huì)影響SQL執(zhí)行效率。

3、無(wú)法獲取鎖

當(dāng)我們?cè)诓僮鲾?shù)據(jù)時(shí)，若別人也在用這張表而且加鎖了，我們無(wú)法獲取到鎖，只能等待他人釋放鎖，這個(gè)很影響SQL效率。

SQL執(zhí)行一直慢的原因分析

如果數(shù)據(jù)量級(jí)不變，而某條SQL執(zhí)行時(shí)一直都很慢，那就需要看看SQL語(yǔ)句寫(xiě)法是否存在問(wèn)題了，另外數(shù)據(jù)庫(kù)的一些配置是否存在問(wèn)題，比如：

1、相關(guān)字段是否建有合適的索引？

比如更新操作，如果加了where條件，而條件列字段沒(méi)有索引，那就意味著要全表掃描，這樣一來(lái)SQL慢也就是正常現(xiàn)象了。

2、字段有索引，但SQL并沒(méi)有用到此索引

并不是說(shuō)我們對(duì)字段創(chuàng)建了索引，索引就一定會(huì)生效。在某些情況下，一些SQL寫(xiě)法會(huì)導(dǎo)致索引失效，比如在索引列上使用了函數(shù)。

3、系統(tǒng)采樣統(tǒng)計(jì)失誤導(dǎo)致系統(tǒng)沒(méi)有使用索引而是全表掃描，此時(shí)需要強(qiáng)制使用索引

SQL執(zhí)行時(shí)，數(shù)據(jù)庫(kù)系統(tǒng)會(huì)進(jìn)行一個(gè)預(yù)測(cè)：看是走索引掃描的行數(shù)少，還是全表掃描的行數(shù)少。索引基數(shù)是通過(guò)采樣來(lái)統(tǒng)計(jì)的，存在一定誤差，如果誤差過(guò)大那可能會(huì)使系統(tǒng)錯(cuò)誤的決定使用全表掃描，此時(shí)我們可以在SQL中聲明強(qiáng)制走索引查詢。

4、硬件限制

如果服務(wù)器CPU及磁盤(pán)讀寫(xiě)速度低、內(nèi)存小，那同樣會(huì)影響整個(gè)數(shù)據(jù)庫(kù)性能。

以上就是我的觀點(diǎn)，對(duì)于這個(gè)問(wèn)題大家是怎么看待的呢？歡迎在下方評(píng)論區(qū)交流~我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗(yàn)，我了解更多科技知識(shí)！