說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。
我先給大家丟擲來乙個場景。
假如我們現在是乙個小創業公司（或者是乙個 bat 公司剛興起的乙個新部門），現在註冊使用者就 20 萬，每天活躍使用者就 1 萬，每天單錶資料量就 1000，然後高峰期每秒鐘併發請求最多就 10。天，就這種系統，隨便找乙個有幾年工作經驗的，然後帶幾個剛培訓出來的，隨便乾乾都可以。
結果沒想到我們運氣居然這麼好，碰上個 ceo 帶著我們走上了康莊大道，業務發展迅猛，過了幾個月，註冊使用者數達到了 2000 萬！每天活躍使用者數 100 萬！每天單錶資料量 10 萬條！高峰期每秒最大請求達到 1000！同時公司還順帶著融資了兩輪，進賬了幾個億人民幣啊！公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！
好吧，沒事，現在大家感覺壓力已經有點大了，為啥呢？因為每天多 10 萬條資料，乙個月就多 300 萬條資料，現在咱們單錶已經幾百萬資料了，馬上就破千萬了。但是勉強還能撐著。高峰期請求現在是 1000，咱們線上部署了幾台機器，負載均衡搞了一下，資料庫撐 1000qps 也還湊合。但是大家現在開始感覺有點擔心了，接下來咋整呢......
再接下來幾個月，我的天，ceo 太牛逼了，公司使用者數已經達到 1 億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成為了國內今年最牛逼的明星創業公司！天，我們太幸運了。
但是我們同時也是不幸的，因為此時每天活躍使用者數上千萬，每天單錶新增資料多達 50 萬，目前乙個表總資料量都已經達到了兩三千萬了！扛不住啊！資料庫磁碟容量不斷消耗掉！高峰期併發達到驚人的5000~8000！別開玩笑了，哥。我跟你保證，你的系統支撐不到現在，已經掛掉了！
好吧，所以你看到這裡差不多就理解分庫分表是怎麼回事兒了，實際上這是跟著你的公司業務發展走的，你公司業務發展越好，使用者就越多，資料量越大，請求量越大，那你單個資料庫一定扛不住。
比如你單錶都幾千萬資料了，你確定你能扛住麼？絕對不行，單錶資料量太大，會極大影響你的 sql 執行的效能，到了後面你的 sql 可能就跑的很慢了。一般來說，就以我的經驗來看，單錶到幾百萬的時候，效能就會相對差一些了，你就得分表了。
分表是啥意思？就是把乙個表的資料放到多個表中，然後查詢的時候你就查乙個表。比如按照使用者 id 來分表，將乙個使用者的資料就放在乙個表中。然後操作的時候你對乙個使用者就操作那個表就好了。這樣可以控制每個表的資料量在可控的範圍內，比如每個表就固定在 200 萬以內。
分庫是啥意思？就是你乙個庫一般我們經驗而言，最多支撐到併發 2000，一定要擴容了，而且乙個健康的單庫併發值你最好保持在每秒 1000 左右，不要太大。那麼你可以將乙個庫的資料拆分到多個庫中，訪問的時候就訪問乙個庫好了。
這就是所謂的分庫分表，為啥要分庫分表？你明白了吧。
#分庫分表前
分庫分表後
併發支撐情況
mysql 單機部署，扛不住高併發
mysql從單機到多機，能承受的併發增加了多倍
磁碟使用情況
mysql 單機磁碟容量幾乎撐滿
拆分為多個庫，資料庫伺服器磁碟使用率大大降低
sql 執行效能
單錶資料量太大，sql 越跑越慢
單錶資料量減少，sql 執行效率明顯提公升
這個其實就是看看你了解哪些分庫分表的中介軟體，各個中介軟體的優缺點是啥？然後你用過哪些分庫分表的中介軟體。
比較常見的包括：
阿里 b2b 團隊開發和開源的，屬於 proxy 層方案，就是介於應用伺服器和資料庫伺服器之間。應用程式通過 jdbc 驅動訪問 cobar 集群，cobar 根據 sql 和分庫規則對 sql 做分解，然後分發到 mysql 集群不同的資料庫例項上執行。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態吧。而且不支援讀寫分離、儲存過程、跨庫 join 和分頁等操作。
**團隊開發的，屬於 client 層方案。支援基本的 crud 語法和讀寫分離，但不支援 join、多表查詢等語法。目前使用的也不多，因為還依賴**的 diamond 配置管理系統。
360 開源的，屬於 proxy 層方案，以前是有一些公司在用的，但是確實有乙個很大的問題就是社群最新的維護都在 5 年前了。所以，現在用的公司基本也很少了。
噹噹開源的，屬於 client 層方案。確實之前用的還比較多一些，因為 sql 語法支援也比較多，沒有太多限制，而且目前推出到了 2.0 版本，支援分庫分表、讀寫分離、分布式 id 生成、柔性事務（最大努力送達型事務、tcc 事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從 2017 年一直到現在，是有不少公司在用的），目前社群也還一直在開發和維護，還算是比較活躍，個人認為算是乙個現在也可以選擇的方案。
基於 cobar 改造的，屬於 proxy 層方案，支援的功能非常完善，而且目前應該是非常火的而且不斷流行的資料庫中介軟體，社群很活躍，也有一些公司開始在用了。但是確實相比於 sharding jdbc 來說，年輕一些，經歷的錘煉少一些。
綜上，現在其實建議考量的，就是 sharding-jdbc 和 mycat，這兩個都可以去考慮使用。
sharding-jdbc 這種 client 層方案的優點在於不用部署，運維成本低，不需要**層的二次**請求，效能很高，但是如果遇到公升級啥的需要各個系統都重新公升級版本再發布，各個系統都需要耦合 sharding-jdbc 的依賴；
mycat 這種 proxy 層方案的缺點在於需要部署，自己運維一套中介軟體，運維成本高，但是好處在於對於各個專案是透明的，如果遇到公升級之類的都是自己中介軟體那裡搞就行了。
通常來說，這兩個方案其實都可以選用，但是我個人建議中小型公司選用 sharding-jdbc，client 層方案輕便，而且維護成本低，不需要額外增派人手，而且中小型公司系統複雜度會低一些，專案也沒那麼多；但是中大型公司最好還是選用 mycat 這類 proxy 層方案，因為可能大公司系統和專案非常多，團隊很大，人員充足，那麼最好是專門弄個人來研究和維護 mycat，然後大量專案直接透明使用即可。
水平拆分的意思，就是把乙個表的資料給弄到多個庫的多個表裡去，但是每個庫的表結構都一樣，只不過每個庫表放的資料是不同的，所有庫表的資料加起來就是全部資料。水平拆分的意義，就是將資料均勻放更多的庫里，然後用多個庫來扛更高的併發，還有就是用多個庫的儲存容量來進行擴容。
垂直拆分的意思，就是把乙個有很多欄位的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到乙個表裡去，然後將較多的訪問頻率很低的字段放到另外乙個表裡去。因為資料庫是有快取的，你訪問頻率高的行欄位越少，就可以在快取裡快取更多的行，效能就越好。這個一般在表層面做的較多一些。
這個其實挺常見的，不一定我說，大家很多同學可能自己都做過，把乙個大表拆開，訂單表、訂單支付表、訂單商品表。
還有表層面的拆分，就是分表，將乙個表變成 n 個表，就是讓每個表的資料量控制在一定範圍內，保證 sql 的效能。否則單錶資料量越大，sql 效能就越差。一般是 200 萬行左右，不要太多，但是也得看具體你怎麼操作，也可能是 500 萬，或者是 100 萬。你的sql越複雜，就最好讓單錶行數越少。
好了，無論分庫還是分表，上面說的那些資料庫中介軟體都是可以支援的。就是基本上那些中介軟體可以做到你分庫分表之後，中介軟體可以根據你指定的某個字段值，比如說 userid，自動路由到對應的庫上去，然後再自動路由到對應的表裡去。
你就得考慮一下，你的專案裡該如何分庫分表？一般來說，垂直拆分，你可以在表層面來做，對一些字段特別多的表做一下拆分；水平拆分，你可以說是併發承載不了，或者是資料量太大，容量承載不了，你給拆了，按什麼欄位來拆，你自己想好；分表，你考慮一下，你如果哪怕是拆到每個庫里去，併發和容量都ok了，但是每個庫的表還是太大了，那麼你就分表，將這個表分開，保證每個表的資料量並不是很大。
而且這兒還有兩種分庫分表的方式：
range 來分，好處在於說，擴容的時候很簡單，因為你只要預備好，給每個月都準備乙個庫就可以了，到了乙個新的月份的時候，自然而然，就會寫新的庫了；缺點，但是大部分的請求，都是訪問最新的資料。實際生產用 range，要看場景。
hash 分發，好處在於說，可以平均分配每個庫的資料量和請求壓力；壞處在於說擴容起來比較麻煩，會有乙個資料遷移的過程，之前的資料需要重新計算 hash 值重新分配到不同的庫或表。
11 分庫分表
雪花演算法 單元化 傳統的專案結構將所有子系統的資料都交給乙個mysql，無法支撐 這涉及到資料庫效能的瓶頸 1 資料庫連線數有限 預設100個，單機最大16384 2 表資料量 單機表數量過多，表資料也過多 3 硬體問題 硬體資源不夠 進行了資料庫效能優化之後 引數優化 索引優化 讀寫分離，還是不...
解決資料庫高併發的一種方案 分庫分表
例 qq的登入表。假設qq的使用者有100億，如果只有一張表，每個使用者登入的時候資料庫都要從這100億中查詢，會很慢很慢。如果將這一張表分成100份，每張表有1億條，就小了很多，比如qq0,qq1,qq1 qq99表。使用者登入的時候，可以將使用者的id 100，那麼會得到0 99的數，查詢表的時...
分庫分表方案（一）
零 概述 當活躍連線數量接近或者達到資料庫可以承載的連線數量閾值時將會出現io瓶頸和cpu效能瓶頸，進而導致上層業務系統的併發量 吞吐量出現問題，甚至導致系統崩潰。下面我先來說一下造成io瓶頸和cpu效能瓶頸的原因。cpu瓶頸 當sql語句中含有 join group by order by 以及非...