案例：

發現應用程序慢，開始把目光放在檢查商業邏輯的SQL上面，覺得沒什么問題，但是執行時間大大超出我的預期。

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

根據經驗，對索引字段做MAX或者MIN是很快的，因為索引是有序，優化器直接到索引頭或者尾部去取rowid就可以了。

但是打開程序一看，SQLPReparement里面的句子是這樣的：

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

覺得有問題了，一看執行計劃，恍然大悟：

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個塊，現在對索引做了完全掃描。

對于一致讀和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人人都會寫，但是很多開發人員，在寫這種SQL的時候不會去思考結果產生的過程，以實現為原則，在他們眼中數據庫仍然是黑盒。在測試過程中也沒有仔細觀察效率，在測試表數據較少，人眼感覺不出來問題，一在生產庫跑就越來越慢。

所以，無論是開發和DBA多學習數據庫的執行機制和原理，是沒有害處的。