一畢業就接觸優化方面的問題，專業做優化也有至少5年之多的時間了，可現在還是經常聽到很多人認為優化很簡單，就是建索引的問題，這確實不能怪大家，做這行20多年的時間裏，在職業生涯的每個階段，幾乎都能聽到這樣的聲音，在很多書上也看到過這樣的說法，但這裏我想告訴大家：優化絕不只是建索引，優化也不是很簡單的事兒，這項工作需要全面的數據庫基礎知識，深刻的概念理解，還要有豐富的實踐經驗。

數據庫的優化，大體可以分為OS、DB和SQL層面的優化。先拋開OS和DB層面不說，我們就先說SQL語句的優化（SQL TUNING），說到SQL的優化，就讓我們不得不提到執行計劃（explain plan），所有的關系型數據庫（oracle,db2,sqlserver,mysql,postgresql,gp等），針對SQL語句，都有相應的執行計劃，只是表現形式不同而已。執行計劃裏包括了多個節點或步驟，根據SQL復雜度的不同，節點或多或少，這些節點裏，有多種數據的訪問方法，也有多種節點之間數據的計算方法，而索引，只是多種數據訪問方法裏的一種而已，再拋開那些計算節點和其他數據訪問節點，僅僅索引訪問數據的方法，又分為很多種，大家可以看看，拋開了這麽多方面和內容，僅僅索引還有這麽多內容學習和研究。

說到了訪問數據的方法，最常見的就是全表掃描和索引訪問了，現在很多人，甚至很多IT人一見到全表掃描就認為執行計劃出現了問題，甚至大聲驚呼，好像發現了新大陸，其實，全表掃描有自己的適用場景，而索引訪問也有自己的適用場景，並不是任何時候通過索引訪問數據才是最優的，最淺顯的，訪問表裏的大部分數據，全表掃描就可能比索引訪問要好些，還有一點，就是索引的cluster factor，當這個值很高的時候（也許很多朋友註意到，有時一個SQL的邏輯讀比整張表都大很多，僅此而已），即使你訪問的數據比例不大，也可能走全表掃描，而在多個不同字段上建的索引存在的情況下，cluster factor的問題幾乎是不可避免的，所以，要想真正的掌握優化，我們必須知道並深入理解數據庫涉及的基礎知識和概念，只有這樣，我們才能搞清楚，什麽情況下，什麽樣的訪問方法和算法是最合適的。

SQL TUNING確實對職業人員的要求較高，但這只是解決了應用層面的問題，不可否認，在很多情況下，系統性能甚至故障是由SQL導致的，但在很多情況下，即使把SQL TUNING的再好，也是解決不了性能問題，這就要求我們對OS和DB層面進行整體分析和調優。

這篇文章到此為止，只是告訴大家，調優不僅僅是索引問題，還有很多方面需要我們去學習和研究，至於OS、DB和SQL TUNING調優的具體方法和步驟，請查閱本博客其他文章。

數據庫性能優化（database tuning）性能優化絕不僅僅只是索引