資料庫效能最佳化（database tuning）效能最佳化絕不僅僅只是索引

一畢業就接觸最佳化方面的問題，專業做最佳化也有至少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調優的具體方法和步驟，請查閱本部落格其他文章。