第0章　引言

筆者早年間從事了多年開發工作，后因個人興趣轉做數據庫。在長期的工作實踐中，看到了數據庫工作（特別是SQL優化）面臨的種種問題，同時也發現人們在對數據庫優化的認識上存在一些誤區。

1.面臨的問題

• 沒有專職人員：在很多公司或者說絕大多數公司，沒有獨立的數據庫團隊。往往由開發人員完成部分DBA的職責，包括結構設計、SQL優化甚至部分運維工作。受限于自身的精力，開發人員很難做到專業化。
• “趕工期”現象：在項目驅動的公司，經常出現趕工期的現象，而且往往犧牲的就是數據庫的設計、評測、優化的時間。常常只是開發完畢后就匆忙上線，直到在線上運行出現問題后才會回頭進行處理。但這時往往已經造成了很大的損失。
• 話語權不大：數據庫團隊在公司中或者在項目中，往往話語權不高。在很多產品、項目決策過程中，常常會忽略DBA的聲音。
• 需求不明：很多項目在設計初期，往往對業務描述很詳盡，但對數據庫卻只字未提。相關數據庫的存儲量、訪問特征、高峰時間的TPS及QPS等往往只有到上線后才有比較清晰的認識。其后果就是往往需要大量優化工作，甚至導致需要對底層架構進行修改，這樣最終會導致成本大大提高，有時增加的成本甚至是不可接受的。
• 重運維、不重架構設計：有些公司認識到數據庫的重要性，但往往只重視運維而忽視了前期的架構設計、開發優化等問題。系統上線后暴露出問題后，只能采取事后補救措施，但這往往會帶來高昂的成本。
• 盲目優化：有些公司確實很重視SQL優化工作，但又缺乏必要的技術投入。經常見到這樣的開發規范——所有WHERE條件字段都必須加上索引。其結果就是數據庫被“過分”優化，適得其反。

2.常見誤區

• 關系數據庫已死：近些年來，隨著NoSQL的蓬勃發展，有一種觀點也逐漸盛行——關系數據庫必將死亡，NoSQL將取而代之！隨之而來的就是SQL優化沒有必要，不必在其上再花費很大力氣。NoSQL作為一種新興的技術，的確有其鮮明的特點，也適用于一些場合。但我們要看到，很多需要ACID的場景下，傳統數據庫仍然是不二選擇，不可取代。
• “SQL優化”很簡單：有些人認為，SQL優化很簡單，甚至碰到過這種觀點——SQL優化不就是加幾個索引嘛，有啥難的！其帶來的直接后果就是，不重視這部分工作。筆者也確實在某業務系統（OLTP）中，觀察到單表存在30多個索引的情況。也遇到過，因為索引過多導致執行性能出現問題的情況。這種情況，往往只有在血淋淋的事故后，才能引起領導的重視。
• 硬件技術發展很快，不用再計較SQL優化：確實，硬件技術近些年來發展迅速，特別是以多核CPU為代表的并行處理技術和以SSD為代表的存儲技術。這些新技術的使用，使得服務器的處理能力有了極大的提升。但我們清醒地看到，SQL優化才是問題的根本解決之道。我們后面可以看到一條SQL語句，可以輕易跑死一個數據庫。這不是簡單地通過硬件升級就可以解決的問題。
• SQL優化只是DBA的事情：在很多設計、開發、測試人員的眼中，SQL優化只是DBA的事情，他們不需要去關心。落實到具體工作中，相關人員就缺乏相應的優化意識，只注重自身功能的實現而忽略了相應的執行成本。最終的結果往往就是代碼質量不高，上線后問題過多。
• 數據倉庫都使用Hadoop，不用傳統關系型數據庫了：Hadoop作為一種新興技術，被越來越多地用在數據分析領域。很多國內外的大型公司，都采用了這個解決方案。但我們清醒地看到，它的定位更傾向于是一種“離線數據分析平臺”，而不是“分布式數據庫”。其時效性、準確性等難以滿足特性需求。現在有很多公司在Hadoop上面做了類似“SQL引擎”的東西，就是仿照關系數據庫的處理方式處理Hadoop中的數據，但要想達到發展了數十年的數據庫水平，還有很長的路要走。筆者對這兩者的認識是：各有所長，互為補充。