溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
MySQL 中怎么實現分庫分表，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
不管是IO瓶頸，還是CPU瓶頸，最終都會導致數據庫的活躍連接數增加，進而逼近甚至達到數據庫可承載活躍連接數的閾值。在業務Service來看就是，可用數據庫連接少甚至無連接可用。接下來就可以想象了吧（并發量、吞吐量、崩潰）。
第一種：磁盤讀IO瓶頸，熱點數據太多，數據庫緩存放不下，每次查詢時會產生大量的IO，降低查詢速度 -> 分庫和垂直分表。
第二種：網絡IO瓶頸，請求的數據太多，網絡帶寬不夠 -> 分庫。
第一種：SQL問題，如SQL中包含join，group by，order by，非索引字段條件查詢等，增加CPU運算的操作 -> SQL優化，建立合適的索引，在業務Service層進行業務計算。
第二種：單表數據量太大，查詢時掃描的行太多，SQL效率低，CPU率先出現瓶頸 -> 水平分表。
img
概念：以 字段為依據，按照一定策略（hash、range等），將一個 庫中的數據拆分到多個 庫中。
結果：
每個 庫的 結構都一樣；
每個 庫的 數據都不一樣，沒有交集；
所有 庫的 并集是全量數據；
場景：系統絕對并發量上來了，分表難以根本上解決問題，并且還沒有明顯的業務歸屬來垂直分庫。
分析：庫多了，io和cpu的壓力自然可以成倍緩解。
img
概念：以 字段為依據，按照一定策略（hash、range等），將一個 表中的數據拆分到多個 表中。
結果：
每個 表的 結構都一樣；
每個 表的 數據都不一樣，沒有交集；
所有 表的 并集是全量數據；
場景：系統絕對并發量并沒有上來，只是單表的數據量太多，影響了SQL效率，加重了CPU負擔，以至于成為瓶頸。
分析：表的數據量少了，單次SQL執行效率高，自然減輕了CPU的負擔。
img
概念：以 表為依據，按照業務歸屬不同，將不同的 表拆分到不同的 庫中。
結果：
每個 庫的 結構都不一樣；
每個 庫的 數據也不一樣，沒有交集；
所有 庫的 并集是全量數據；
場景：系統絕對并發量上來了，并且可以抽象出單獨的業務模塊。
分析：到這一步，基本上就可以服務化了。例如，隨著業務的發展一些公用的配置表、字典表等越來越多，這時可以將這些表拆到單獨的庫中，甚至可以服務化。再有，隨著業務的發展孵化出了一套業務模式，這時可以將相關的表拆到單獨的庫中，甚至可以服務化。
img
概念：以 字段為依據，按照字段的活躍性，將 表中字段拆到不同的 表（主表和擴展表）中。
結果：
每個 表的 結構都不一樣；
每個 表的 數據也不一樣，一般來說，每個表的 字段至少有一列交集，一般是主鍵，用于關聯數據；
所有 表的 并集是全量數據；
場景：系統絕對并發量并沒有上來，表的記錄并不多，但是字段多，并且熱點數據和非熱點數據在一起，單行數據所需的存儲空間較大。以至于數據庫緩存的數據行減少，查詢時會去讀磁盤數據產生大量的隨機讀IO，產生IO瓶頸。
分析：可以用列表頁和詳情頁來幫助理解。垂直分表的拆分原則是將熱點數據（可能會冗余經常一起查詢的數據）放在一起作為主表，非熱點數據放在一起作為擴展表。這樣更多的熱點數據就能被緩存下來，進而減少了隨機讀IO。拆了之后，要想獲得全部數據就需要關聯兩個表來取數據。但記住，千萬別用join，因為join不僅會增加CPU負擔并且會講兩個表耦合在一起（必須在一個數據庫實例上）。關聯數據，應該在業務Service層做文章，分別獲取主表和擴展表數據然后用關聯字段關聯得到全部數據。
sharding-sphere：jar，前身是sharding-jdbc；
TDDL：jar，Taobao Distribute Data Layer；
Mycat：中間件。
注：工具的利弊，請自行調研，官網和社區優先。
根據容量（當前容量和增長量）評估分庫或分表個數 -> 選key（均勻）-> 分表規則（hash或range等）-> 執行（一般雙寫）-> 擴容問題（盡量減少數據的移動）。
基于水平分庫分表，拆分策略為常用的hash法。
注： 寫入時，基因法生成user_id，如圖。 關于xbit基因，例如要分8張表，23=8，故x取3，即3bit基因。 根據user_id查詢時可直接取模路由到對應的分庫或分表。 根據user_name查詢時，先通過user_name_code生成函數生成user_name_code再對其取模路由到對應的分庫或分表。 id生成常用 snowflake算法 。
注：按照order_id或buyer_id查詢時路由到db_o_buyer庫中，按照seller_id查詢時路由到db_o_seller庫中。感覺有點本末倒置！有其他好的辦法嗎？改變技術棧呢？
端上除了partition key只有一個非partition key作為條件查詢
映射法
基因法
端上除了partition key不止一個非partition key作為條件查詢
映射法
冗余法
后臺除了partition key還有各種非partition key組合條件查詢
冗余法 
基于水平分庫分表，拆分策略為常用的hash法。
注：用**NoSQL法**解決（ES等）。
基于水平分庫分表，拆分策略為常用的hash法。
水平擴容庫（升級從庫法）
注：擴容是成倍的。
水平擴容表（雙寫遷移法）
第一步：（同步雙寫）修改應用配置和代碼，加上雙寫，部署；第二步：（同步雙寫）將老庫中的老數據復制到新庫中；第三步：（同步雙寫）以老庫為準校對新庫中的老數據；第四步：（同步雙寫）修改應用配置和代碼，去掉雙寫，部署；
注： 雙寫是通用方案。
分庫分表，首先得知道瓶頸在哪里，然后才能合理地拆分（分庫還是分表？水平還是垂直？分幾個？）。且不可為了分庫分表而拆分。
選key很重要，既要考慮到拆分均勻，也要考慮到非partition key的查詢。
只要能滿足需求，拆分規則越簡單越好。
看完上述內容，你們掌握MySQL 中怎么實現分庫分表的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
