MySQL查詢緩慢的N種原因,以及N+1種解決方法
昨天查詢數(shù)據(jù)庫的時還正常,今早來上班時,SQL語句查詢就突然變得很慢了。這樣的情況我相信你一定遇到過。 下面就讓小編來帶你了解其中的原因吧!
本篇文章簡單總結(jié)了一下可能導(dǎo)致數(shù)據(jù)庫查詢慢的原因,希望能給大家后續(xù)查詢優(yōu)化提供一下指導(dǎo)。
SQL語句查詢突然變得很慢,常見的情況有以下幾種:
- 電腦系統(tǒng)內(nèi)存不足:和咱們的電腦一樣,當(dāng)內(nèi)存不足的時候,就會變得很卡!
- 網(wǎng)速突然降速了:當(dāng)網(wǎng)絡(luò)速度變慢,HTTP 的請求也會變慢!
- 你所寫的SQL語句不是***解
兩個原則
兩條快于一條:
***條SQL語句中,where查詢語句中出現(xiàn)了null,這樣就是導(dǎo)致數(shù)據(jù)庫的引擎不會使用索引,而采取的是進行全表掃描一遍,這樣的查詢就會變得很慢。如果使用0來代替null,即為第二條SQL語句,則數(shù)據(jù)庫查詢運行速度的就會提高
精準(zhǔn)快于全表:
很明顯,***條SQL語句的執(zhí)行速度要比第二條SQL語句快的多。因為***條SQL語句使用的是精準(zhǔn)查詢,索引查詢;第二條SQL語句是將表中所有的數(shù)據(jù)都檢索一遍,相當(dāng)于全表查詢,這樣是很消耗時間的和資源的。
查詢的數(shù)據(jù)庫數(shù)據(jù)量變得很大
當(dāng)你SQL Server 中所查詢的數(shù)據(jù)量很大時,也會造成你的數(shù)據(jù)庫很慢。
比方說 :我有一個數(shù)據(jù)量達到幾百萬的商品表,現(xiàn)在我需要查里面某些商品的信息,這樣的查詢也會很慢哦!例如:
表中數(shù)據(jù)上百萬的數(shù)據(jù)量,要在這海量的數(shù)據(jù)中找到你所需要的商品信息,如果你寫上這樣的SQL語句,查詢速度必須慢!
解決方案:
使用索引:
- //--建立索引
這樣的情況下,可以明顯增加查詢時間。因為使用了索引,可以在海量的數(shù)據(jù)中,快速的找到你所需要的信息,而不是在上百萬的表數(shù)據(jù)中,一個個的檢索到你所需要的信息。
數(shù)據(jù)庫發(fā)生死鎖現(xiàn)象
我們知道當(dāng)程序發(fā)生死鎖現(xiàn)象之后,程序就會卡在那個位置會變得很慢,很慢甚至一點都不動。所以,當(dāng)你的SQL語句出現(xiàn)死鎖現(xiàn)象之后,數(shù)據(jù)庫查詢也會很慢!
數(shù)據(jù)庫死鎖現(xiàn)象是指:兩個或者是兩個以上的SQL語句,爭相訪問同一個數(shù)據(jù)表,并且在***天SQL語句訪問表的時候,同時將數(shù)據(jù)表給鎖住了。就會造成第二條,第三條SQL語句不能訪問到表而進行遲遲等待。如果沒有人員原因干預(yù)的話,就是一直處于這種狀態(tài)下,所以叫做死鎖。
解決方法:
這種SQL語句發(fā)送死鎖現(xiàn)象,一般都是bug造成的。修改程序的邏輯順序,給出一個合適的程序執(zhí)行邏輯順序。避免同時鎖定兩個資源的現(xiàn)象發(fā)生。給SQL語句安排一個先后順序。
I/O 執(zhí)行響應(yīng)時間太長
我們都知道木桶原理,決定盛水多少的,不是長木板而是那些短木板。同樣,對于數(shù)據(jù)庫而言 ,電腦系統(tǒng)的硬件設(shè)備 ——磁盤I/O 則是短木板。在程序執(zhí)行中,我們經(jīng)常會發(fā)現(xiàn)系統(tǒng)中的I/O,一直在不停地執(zhí)行,而CPU卻在清閑的等待。造成這種原因的發(fā)生是因為,磁盤的I/O(即磁盤的讀寫速度)遠遠跟不上CPU的處理速度。
優(yōu)化方案:
- 盡可能的將程序放到內(nèi)存中去執(zhí)行
- 當(dāng)讀寫I/O響應(yīng)速度跟不上時,增加硬盤的個數(shù),擴大存儲
- 盡可能的選擇一些讀寫速度高的磁盤來解決問題(ssd)
End
當(dāng)?shù)诙齑蜷_電腦時,發(fā)現(xiàn)數(shù)據(jù)庫變得緩慢時,不妨試一試上面的方法,一定可以有意想不到的驚喜收獲。