數(shù)據(jù)庫查詢慢的原因

1、數(shù)據(jù)庫查詢慢的原因一般關(guān)系型數(shù)據(jù)庫的物理存儲分為堆和B+樹，一般索引的存儲結(jié)構(gòu)為 B+樹，而數(shù)據(jù)表如果沒有建立聚集索引的話，數(shù)據(jù)就是堆存儲。這兩 種存儲結(jié)構(gòu)會很大程度上印象查詢效率，B+樹可以按照Key進行定向 查找，而堆只能逐行掃描。這就像去圖書館找一本書，通過索引號可以 快速找到其位置，而從書架上一排排看過去效率就很低。這里需要說明一下，并非B+樹的存儲結(jié)構(gòu)永遠比堆存儲結(jié)構(gòu)好，至于 什么情況下適合用堆存儲，大家可以討論一下。查找效率低我們知道非聚集索引只是存儲了索引本身包含的字段以及聚集索引的 字段（如果有的話），所以如果按照非聚集索引查找，很可能還需要二 次查找，也就是非聚集索引只是提供

2、了數(shù)據(jù)的實際存儲地址，還需要額 外的磁盤IO去實際存儲地址查找，這就會在一定程度上影響查詢性能。查找效率還會受列存儲和行存儲的影響，列存儲是按照表格中的同一列 數(shù)據(jù)一起存儲，而行存儲是把表格中的數(shù)據(jù)一行一行的一起存儲，這兩 種存儲方式也會對查找效率造成影響。磁& IO過高一般查詢引擎都是按照數(shù)據(jù)塊讀取，只要某個數(shù)據(jù)塊中有需要的數(shù)據(jù)， 那么就會把這個數(shù)據(jù)塊讀取到內(nèi)存中，所以如果數(shù)據(jù)過于分散，也會很 大程度上影響查詢效率，表現(xiàn)為磁盤IO很高。這方面涉及到索引碎片， 索引重建，索引整理等技術(shù)。另外數(shù)據(jù)的壓縮比也會影響到磁盤的IO，理論上壓縮比越高，數(shù)據(jù)讀 取的效率越高，相同情況下磁盤IO會低很多，但

3、是數(shù)據(jù)壓縮意味著存 儲時需要壓縮，讀取后需要解壓，所以需要綜合考慮，并非壓縮比越高 越好。查詢等待時間過長有時候分析查詢過程會發(fā)現(xiàn)，執(zhí)行耗時很短，反而大部分時間都在排隊， 這種現(xiàn)象在多產(chǎn)品共用一個查詢平臺時最容易出現(xiàn)（請允許我先哭上三 分鐘.），導(dǎo)致這種情況一般是系統(tǒng)資源不足（內(nèi)存不足等），導(dǎo)致 無法為查詢分配足夠的資源執(zhí)行。查詢等待還經(jīng)常會因為鎖等待導(dǎo)致，也就是當我想查這行數(shù)據(jù)時，其他 人正在對這行數(shù)據(jù)進行編輯（排它鎖），這時候我就需要等對方編輯完 成才能讀取。這方面根據(jù)實際場景可以考慮臟讀等方式。網(wǎng)絡(luò)傳輸原因數(shù)據(jù)在服務(wù)器端查詢完成之后一般都需要通過網(wǎng)絡(luò)傳輸?shù)娇蛻舳耍@時 候如果一次返回的數(shù)

4、據(jù)量過大，也會導(dǎo)致用戶感覺查詢變慢，這種情況 需要應(yīng)用端進行分頁處理，或者對數(shù)據(jù)進行壓縮傳輸。執(zhí)行計劃不合理因為索弓I碎片過大或者統(tǒng)計信息缺失等原因會造成數(shù)據(jù)庫的查詢引擎 生成一些不夠合理的查詢計劃，這時候推薦的做法是重建索引或者更新 統(tǒng)計信息，當然也可以使用hint的方式強制更改查詢計劃，但這種方 式很容易遺忘，引發(fā)后續(xù)其他情況下的查詢問題。系統(tǒng)資源不足或者被搶占現(xiàn)在一般服務(wù)器都是采用虛擬化的技術(shù)進行資源隔離，但是很多虛擬化 技術(shù)無法控制CPU的隔離，所以如果其他應(yīng)用占用了大量CPU資源可 能會導(dǎo)致數(shù)據(jù)庫查詢慢。數(shù)據(jù)庫的查詢操作一般都現(xiàn)在內(nèi)存中查找是否緩存了相應(yīng)數(shù)據(jù)，如果沒 有則需要先把數(shù)據(jù)讀取到內(nèi)存中，這就導(dǎo)致了，當內(nèi)存過低時，會造成 查詢命中率很低，需要頻繁的到磁盤中讀取數(shù)據(jù)，從而影響數(shù)據(jù)庫的查 詢性能。數(shù)據(jù)庫是高內(nèi)存，高IO，高CPU的應(yīng)用，所以一般推薦一個物理機上 不要開多個數(shù)據(jù)庫服務(wù)器，避免相互搶占資源。硬件配置不足上面提到，數(shù)據(jù)庫是高內(nèi)存，高IO，高CPU的應(yīng)用，