這篇論壇文章(賽迪網技術社區(qū))主要介紹了一個導致應用程序越來越慢的的實際案例，詳細內容請參考下文：
案例：
發(fā)現(xiàn)應用程序慢，開始把目光放在檢查商業(yè)邏輯的SQL上面，覺得沒什么問題，但是執(zhí)行時間大大超出我的預期。
后來詢問開發(fā)人員，原來最初會取工單表里面的最近工單時間，最早工單時間來做對比。
根據(jù)經驗，對索引字段做MAX或者MIN是很快的，因為索引是有序，優(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
完美解決。
總結：
其實這個問題很小，這個SQL人人都會寫，但是很多開發(fā)人員，在寫這種SQL的時候不會去思考結果產生的過程，以實現(xiàn)為原則，在他們眼中數(shù)據(jù)庫仍然是黑盒。在測試過程中也沒有仔細觀察效率，在測試表數(shù)據(jù)較少，人眼感覺不出來問題，一在生產庫跑就越來越慢。
所以，無論是開發(fā)和DBA多學習數(shù)據(jù)庫的執(zhí)行機制和原理，是沒有害處的。
關鍵詞標簽：mssql
相關閱讀
熱門文章
SqlServer2005對現(xiàn)有數(shù)據(jù)進行分區(qū)具體步驟
sql server系統(tǒng)表損壞的解決方法
MS-SQL2005服務器登錄名、角色、數(shù)據(jù)庫用戶
Access、SQL Server、Oracle常見應用的區(qū)別
人氣排行 如何遠程備份（還原）SQL2000數(shù)據(jù)庫SQL2000數(shù)據(jù)庫遠程導入（導出）數(shù)據(jù)配置和注冊ODBC數(shù)據(jù)源-odbc數(shù)據(jù)源配置教程SQL2000和SQL2005數(shù)據(jù)庫服務端口查看或修改SQL Server 2005降級到2000的正確操作步驟修改Sql Server唯一約束教程淺談JSP JDBC來連接SQL Server 2005的方法SQL Server創(chuàng)建表語句介紹