IT貓撲網(wǎng):您身邊最放心的安全下載站! 最新更新|軟件分類|軟件專題|手機版|論壇轉(zhuǎn)貼|軟件發(fā)布

您當(dāng)前所在位置:首頁數(shù)據(jù)庫MSSQL → 用一個案例講解應(yīng)用程序越來越慢的原因

用一個案例講解應(yīng)用程序越來越慢的原因

時間:2015/6/28來源:IT貓撲網(wǎng)作者:網(wǎng)管聯(lián)盟我要評論(0)

這篇論壇文章(賽迪網(wǎng)技術(shù)社區(qū))主要介紹了一個導(dǎo)致應(yīng)用程序越來越慢的的實際案例,詳細(xì)內(nèi)容請參考下文:

案例:

發(fā)現(xiàn)應(yīng)用程序慢,開始把目光放在檢查商業(yè)邏輯的SQL上面,覺得沒什么問題,但是執(zhí)行時間大大超出我的預(yù)期。

后來詢問開發(fā)人員,原來最初會取工單表里面的最近工單時間,最早工單時間來做對比。

根據(jù)經(jīng)驗,對索引字段做MAX或者M(jìn)IN是很快的,因為索引是有序,優(yōu)化器直接到索引頭或者尾部去取rowid就可以了。

但是打開程序一看,SQLpreparement里面的句子是這樣的:

select min(billtime),MAX(billtime) from billcontent

覺得有問題了,一看執(zhí)行計劃,恍然大悟:

Execution Plan

----------------------------------------------------------

Plan hash value: 1499044795

----------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

----------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 8 | 5126 (3)| 00:01:02 | | |

| 1 | SORT AGGREGATE | | 1 | 8 | | | | |

| 2 | PARTITION RANGE SINGLE| | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 1 |

| 3 | PARTITION LIST ALL | | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 21 |

| 4 | INDEX FAST FULL SCAN| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 21 |

------------------------------------------------------------

Statistics

----------------------------------------------------------

26745 consistent gets

是INDEX FAST FULL SCAN,26745 個一致讀,5126 的Cost,大概查了一下,該索引擁有27632個塊,現(xiàn)在對索引做了完全掃描。

對于一致讀和Cost的計算方法,這里暫不多述。

只查一個極限值話:

select min(billtime) from billcontent;

Execution Plan

----------------------------------------------------------

Plan hash value: 4137395070

-----------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

-----------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 8 | 3 (0)| 00:00:01 | | |

| 1 | SORT AGGREGATE | | 1 | 8 | | | | |

| 2 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |

| 3 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

| 4 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

--------------------------------------------------------------

Statistics

----------------------------------------------------------

42 consistent gets

計劃是INDEX FULL SCAN (MIN/MAX),(MIN/MAX)表明只會訪問索引的頭或尾,開銷大大減小,只有42個一致讀和極低的Cost,正常情況只能是

這個的兩倍多。

馬上動手改為:

SELECT

(select min(calltime) from analyse_content ),

(select MAX(calltime) from analyse_content )

FROM dual

Execution Plan

----------------------------------------------------------

Plan hash value: 2326664376

-----------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

-----------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | | 2 (0)| 00:00:01 | | |

| 1 | SORT AGGREGATE | | 1 | 8 | | | | |

| 2 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |

| 3 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

| 4 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

| 5 | SORT AGGREGATE | | 1 | 8 | | | | |

| 6 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |

| 7 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

| 8 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |

| 9 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |

-------------------------------------------------------------

Statistics

----------------------------------------------------------

84 consistent gets

完美解決。

總結(jié):

其實這個問題很小,這個SQL人人都會寫,但是很多開發(fā)人員,在寫這種SQL的時候不會去思考結(jié)果產(chǎn)生的過程,以實現(xiàn)為原則,在他們眼中數(shù)據(jù)庫仍然是黑盒。在測試過程中也沒有仔細(xì)觀察效率,在測試表數(shù)據(jù)較少,人眼感覺不出來問題,一在生產(chǎn)庫跑就越來越慢。

所以,無論是開發(fā)和DBA多學(xué)習(xí)數(shù)據(jù)庫的執(zhí)行機制和原理,是沒有害處的。

關(guān)鍵詞標(biāo)簽:mssql

相關(guān)閱讀

文章評論
發(fā)表評論

熱門文章 SqlServer2005對現(xiàn)有數(shù)據(jù)進(jìn)行分區(qū)具體步驟SqlServer2005對現(xiàn)有數(shù)據(jù)進(jìn)行分區(qū)具體步驟sql server系統(tǒng)表損壞的解決方法sql server系統(tǒng)表損壞的解決方法MS-SQL2005服務(wù)器登錄名、角色、數(shù)據(jù)庫用戶MS-SQL2005服務(wù)器登錄名、角色、數(shù)據(jù)庫用戶Access、SQL Server、Oracle常見應(yīng)用的區(qū)別Access、SQL Server、Oracle常見應(yīng)用的區(qū)別

相關(guān)下載

人氣排行 如何遠(yuǎn)程備份(還原)SQL2000數(shù)據(jù)庫SQL2000數(shù)據(jù)庫遠(yuǎn)程導(dǎo)入(導(dǎo)出)數(shù)據(jù)配置和注冊O(shè)DBC數(shù)據(jù)源-odbc數(shù)據(jù)源配置教程SQL2000和SQL2005數(shù)據(jù)庫服務(wù)端口查看或修改SQL Server 2005降級到2000的正確操作步驟修改Sql Server唯一約束教程淺談JSP JDBC來連接SQL Server 2005的方法SQL Server創(chuàng)建表語句介紹