架構師必備技能：資料庫優化手術刀——實戰分庫分表
在最初，應用的資料量比較少，沒有任何壓力，一般會將所有的資料放在一個庫中。但是隨著業務的增長，資料量急劇增長，DB壓力增大，似乎隨時都會掛掉。此時，優化DB的使用已經是勢在必行，以下有幾個方案。
1
優化對DB的使用
讀寫分離（肯定一開始就做了……）、索引、使用合理的sql等等。一些簡單的優化可以先做，複雜的優化如果時間允許能先做是最好的，但如果是一直被業務趕著走，抽不出時間做，只好先選擇其它的措施。
2
升級機器配置
升級機器配置，加CPU、加記憶體，換SSD。簡單粗暴，無論怎麼樣，機器比人便宜，如果沒時間做業務上的優化，先走這條路，直到最後升級機器已經沒有效果。
3
拆庫
隨著業務的繼續發展，最終，機器也升級到沒得升了，基本的sql優化也做了，但資料庫還是扛不住。只能開始拆庫，可以選擇垂直拆分與水平拆分。
其中垂直拆分是最簡單的，也是成本最低的，對線上業務的影響也不大。可以按業務模組進行拆分，這樣相對清晰。可以將新拆分出來的庫作為原來庫的從庫，保持資料的同步。挑個流量低峰時間做切換，先關閉寫入服務，之後將服務切換到新拆分出來的庫即可。
按業務模組拆分資料庫以後，可以支撐業務的執行很長時間了。除非，某個業務模組已經發展到單DB、抑或單表也無法支撐的程度。這個時候需要著手進行水平拆分了，按什麼維度進行拆分需要綜合考慮事務支援、資料的分佈是否均勻、能否方便後續的資料處理等問題，一般選擇使用者id，業務編號等。
水平拆分可選擇取模，或者波動更小的一致性hash。但是無論是取模還是一致性hash，都涉及到如何選擇拆分的規模的問題，也即初始我們要拆分多少個表，多少個庫，拆小了，跟不上業務的發展，很快就得繼續做拆分。拆大了，機器閒置也浪費資源。
這就牽扯到未來如果加機器，如何平滑過渡，最好都不用停機的問題。畢竟，7*24小時才是網際網路服務的正確姿勢。 之前網上看到過一個方案可以借鑑下。
Java
就是在前面加一個索引，儲存當前資料的對映，新增資料庫以後，所有操作都先查索引，獲取對映的庫進行相應的操作。那麼對於舊的資料，還是到原來的db讀寫。新的資料由於索引不存在，重新計算其索引，並落到對應的DB。另外，其任務對舊資料進行遷移，不過要注意遷移的過程要對資料進行鎖定，防止不一致的情況，在流量低峰進行即可。這個方案配合一致性雜湊會好一些，需要遷移的資料相對少。
每晚8:00燭光學院的講師將會在騰訊課堂燭光學院Java高階免費試聽課程中給大家詳細講解資料庫呦
Java學習資料獲取或免費進入課堂許可權獲取（複製下段連線至瀏覽器即可）
data:text/html;charset=UTF-8;base64,5p625p6E5biI5a2m5Lmg6LWE5paZ5YWN6LS56aKG5Y+W6K+35Yqg5omj5omj5Y+35pivMTAxODkyNTc4MA==