昨天查詢數(shù)據(jù)庫的時還正常，今早來上班時，SQL語句查詢就突然變得很慢了。這樣的情況我相信你一定遇到過。 下面就讓小編來帶你了解其中的原因吧!

[[266301]]

本篇文章簡單總結了一下可能導致數(shù)據(jù)庫查詢慢的原因，希望能給大家后續(xù)查詢優(yōu)化提供一下指導。

SQL語句查詢突然變得很慢，常見的情況有以下幾種：

• 電腦系統(tǒng)內存不足：和咱們的電腦一樣，當內存不足的時候，就會變得很卡!
• 網(wǎng)速突然降速了：當網(wǎng)絡速度變慢，HTTP 的請求也會變慢!
• 你所寫的SQL語句不是***解

兩個原則

兩條快于一條：

***條SQL語句中，where查詢語句中出現(xiàn)了null，這樣就是導致數(shù)據(jù)庫的引擎不會使用索引，而采取的是進行全表掃描一遍，這樣的查詢就會變得很慢。如果使用0來代替null，即為第二條SQL語句，則數(shù)據(jù)庫查詢運行速度的就會提高

精準快于全表：

很明顯，***條SQL語句的執(zhí)行速度要比第二條SQL語句快的多。因為***條SQL語句使用的是精準查詢，索引查詢;第二條SQL語句是將表中所有的數(shù)據(jù)都檢索一遍，相當于全表查詢，這樣是很消耗時間的和資源的。

查詢的數(shù)據(jù)庫數(shù)據(jù)量變得很大

當你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)象

我們知道當程序發(fā)生死鎖現(xiàn)象之后，程序就會卡在那個位置會變得很慢，很慢甚至一點都不動。所以，當你的SQL語句出現(xiàn)死鎖現(xiàn)象之后，數(shù)據(jù)庫查詢也會很慢!

數(shù)據(jù)庫死鎖現(xiàn)象是指：兩個或者是兩個以上的SQL語句，爭相訪問同一個數(shù)據(jù)表，并且在***天SQL語句訪問表的時候，同時將數(shù)據(jù)表給鎖住了。就會造成第二條，第三條SQL語句不能訪問到表而進行遲遲等待。如果沒有人員原因干預的話，就是一直處于這種狀態(tài)下，所以叫做死鎖。

解決方法：

這種SQL語句發(fā)送死鎖現(xiàn)象，一般都是bug造成的。修改程序的邏輯順序，給出一個合適的程序執(zhí)行邏輯順序。避免同時鎖定兩個資源的現(xiàn)象發(fā)生。給SQL語句安排一個先后順序。

I/O 執(zhí)行響應時間太長

我們都知道木桶原理，決定盛水多少的，不是長木板而是那些短木板。同樣，對于數(shù)據(jù)庫而言 ，電腦系統(tǒng)的硬件設備 ——磁盤I/O 則是短木板。在程序執(zhí)行中，我們經(jīng)常會發(fā)現(xiàn)系統(tǒng)中的I/O，一直在不停地執(zhí)行，而CPU卻在清閑的等待。造成這種原因的發(fā)生是因為，磁盤的I/O(即磁盤的讀寫速度)遠遠跟不上CPU的處理速度。

優(yōu)化方案：

• 盡可能的將程序放到內存中去執(zhí)行
• 當讀寫I/O響應速度跟不上時，增加硬盤的個數(shù)，擴大存儲
• 盡可能的選擇一些讀寫速度高的磁盤來解決問題(ssd)

End

當?shù)诙齑蜷_電腦時，發(fā)現(xiàn)數(shù)據(jù)庫變得緩慢時，不妨試一試上面的方法，一定可以有意想不到的驚喜收獲。