基本認識
用分庫&拆表是解決資料庫容量問題的唯一途徑。
分庫&拆表也是解決效能壓力的最優選擇。
分庫 – 不同的資料表放到不同的資料庫伺服器中（也可能是虛擬伺服器）
拆表 – 一張資料表拆成多張資料表，可能位於同一臺伺服器，也可能位於多台伺服器（含虛擬伺服器）。
去關聯化原則
摘除資料表之間的關聯，是分庫的基礎工作。
摘除關聯的目的是，當資料表分布到不同伺服器時，查詢請求容易分發和處理。
學會理解反正規化資料結構設計，所謂反正規化，第一要點是不用外來鍵，不允許join操作，不允許任何需要跨越兩個表的查詢請求。第二要點是適度冗餘減少查詢請求，比如說，資訊表，fromuid, touid, message欄位外，還需要乙個fromuname欄位記錄使用者名稱，這樣查詢者通過touid查詢後，能夠立即得到發信人的使用者名稱，而無需進行另乙個資料表的查詢。
去關聯化處理會帶來額外的考慮，比如說，某乙個資料表內容的修改，對另乙個資料表的影響。這一點需要在程式或其他途徑去考慮。
分庫方案
安全性拆分
將高安全性資料與低安全性資料分庫，這樣的好處第一是便於維護，第二是高安全性資料的資料庫引數配置可以以安全優先，而低安全性資料的引數配置以效能優先。參見運維優化相關部分。
順序寫資料與隨機讀寫資料分庫
順序資料與隨機資料區分儲存位址，保證物理i/o優化。
基於業務邏輯拆分
根據資料表的內容構成，業務邏輯拆分，便於日常維護和前端呼叫。
基於業務邏輯拆分，可以減少前端應用請求傳送到不同資料庫伺服器的頻次，從而減少鏈結開銷。
基於業務邏輯拆分，可保留部分資料關聯，前端web工程師可在限度範圍內執行關聯查詢。
基於負載壓力拆分
基於負載壓力對資料結構拆分，便於直接將負載分擔給不同的伺服器。
基於負載壓力拆分，可能拆分後的資料庫包含不同業務型別的資料表，日常維護會有一定的煩惱。
分表方案
資料量過大或者訪問壓力過大的資料表需要切分
忙閒分表
單資料表字段過多，可將頻繁更新的整數資料與非頻繁更新的字串資料切分
橫向切表
等分切表，如雜湊切表或其他基於對某數字取餘的切表。等分切表的優點是負載很方便的分布到不同伺服器；缺點是當容量繼續增加時無法方便的擴容，需要重新進行資料的切分或轉表。而且一些關鍵主鍵不易處理。
遞增切表，比如每1kw使用者開乙個新錶，優點是可以適應資料的自增趨勢；缺點是往往新資料負載高，壓力分配不平均。
日期切表，適用於日誌記錄式資料，優缺點等同於遞增切表。
個人傾向於遞增切表，具體根據應用場景決定。
熱點資料分表
將資料量較大的資料表中將讀寫頻繁的資料抽取出來，形成熱點資料表。通常乙個龐大資料表經常被讀寫的內容往往具有一定的集中性，如果這些集中資料單獨處理，就會極大減少整體系統的負載。
熱點資料表與舊有資料關係
可以是一張冗餘表，即該錶資料丟失不會妨礙使用，因源資料仍存在於舊有結構中。優點是安全性高，維護方便，缺點是寫壓力不能分擔，仍需要同步寫回原系統。
可以是非冗餘表，即熱點資料的內容原有結構不再儲存，優點是讀寫效率全部優化；缺點是當熱點資料發生變化時，維護量較大。
具體方案選擇需要根據讀寫比例決定，在讀頻率遠高於寫頻率情況下，優先考慮冗餘表方案。
熱點資料表可以用單獨的優化的硬體儲存，比如昂貴的快閃儲存器卡或大記憶體系統。
熱點資料表的重要指標
熱點資料的定義需要根據業務模式自行制定策略，常見策略為，按照最新的操作時間；按照內容豐富度等等。
資料規模，比如從1000萬條資料，抽取出100萬條熱點資料。
熱點命中率，比如查詢10次，多少次命中在熱點資料內。
理論上，資料規模越小，熱點命中率越高，說明效果越好。需要根據業務自行評估。
熱點資料表的動態維護
載入熱點資料方案選擇
定時從舊有資料結構中按照新的策略獲取
在從舊有資料結構讀取時動態載入到熱點資料
剔除熱點資料方案選擇
基於特定策略，定時將熱點資料中訪問頻次較少的資料剔除
如熱點資料是冗餘表，則直接刪除即可，如不是冗餘表，需要回寫給舊有資料結構。
通常，熱點資料往往是基於快取或者key-value 方案冗餘儲存，所以這裡提到的熱點資料表，其實更多是理解思路，用到的場合可能並不多….
表結構設計
查詢冗餘表設計
涉及分表操作後，一些常見的索引查詢可能需要跨表，帶來不必要的麻煩。確認查詢請求遠大於寫入請求時，應設定便於查詢項的冗餘表。
實戰範例，
使用者分表，將使用者庫分成若干資料表
基於使用者名稱的查詢和基於uid的查詢都是高併發請求。
使用者分表基於uid分成資料表，同時基於使用者名稱做對應冗餘表。
冗餘表要點
資料一致性，簡單說，同增，同刪，同更新。
可以做全冗餘，或者只做主鍵關聯的冗餘，比如通過使用者名稱查詢uid，再基於uid查詢源表。
中間資料表
為了減少會涉及大規模影響結果集的表資料操作，比如count，sum操作。應將一些統計類資料通過中間資料表儲存。
中間資料表應能通過源資料表恢復。
實戰範例：
論壇板塊的發帖量，回帖量，每日新增資料等
**每日新增使用者數等。
後台可以通過源資料表更新該數字。
歷史資料表
歷史資料表對應於熱點資料表，將需求較少又不能丟棄的資料存入，僅在少數情況下被訪問。
Mysql分庫分表方案
1.為什麼要分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。mysql中有一種機制是表鎖定和行鎖定，是為了保證資料的完整性。表鎖定表示你們都不能對這張表進行操作，必須等我對錶操作完才行。行鎖...
mysql分庫分表方案
分庫分表的幾種方式 1 把乙個例項中的多個資料庫拆分到不同的例項 2 把乙個庫中的表分離到不同的資料庫中 3 對乙個庫中的相關表進行水平拆分到不同的例項資料庫中 如何選擇分割槽鍵 1 分割槽鍵要能盡量避免跨分片查詢的發生 2 分割槽鍵要能盡量使各個分片中的資料平均 如何儲存無需分片的表 1 每個分片...
分庫分表方案（一）
零 概述 當活躍連線數量接近或者達到資料庫可以承載的連線數量閾值時將會出現io瓶頸和cpu效能瓶頸，進而導致上層業務系統的併發量 吞吐量出現問題，甚至導致系統崩潰。下面我先來說一下造成io瓶頸和cpu效能瓶頸的原因。cpu瓶頸 當sql語句中含有 join group by order by 以及非...