場景
一個金融公司有 500w 投資用戶，每天充值投資 50w 筆，那么該公司每年將近有 1 億條充值記錄，那么我們改如何處理這個充值訂單表的數據呢？難不成都放一張表里面，那萬一哪天我讓你去統計滿足某個需求的記錄，1 億條數據里面檢索你會累死 mysql 的！今天我們就來講述一下如何去處理這種情況。
mysql 分布式之分表思路
分表不是隨隨便便就分表，必須要結合項目的實際情況，比如我們的項目的瓶頸在哪里，區區幾千幾萬幾十萬或者幾
百萬的數據用分表那就是高射炮打蚊子了，不要盲目的分表！必須要達到一定的數量級，並且影響了我們的用戶的訪問速度，性能下降的情況下才能考慮去做分表處理！
畫個簡單的不能再簡單的圖吧
分表的思路就是如此簡單，借助中間件可以根據不同省份的訂單插入到不同省份對應的表當中去，當然實際當中還得要結合自身的業務來尋找制作這個中間件，不要照搬人家的邏輯思路！
mysql 分布式之分表實戰（插入總表分然后取模分發到分表）
//偽代碼
//假設用戶數據入庫 定為每天50w的數據量入庫
//我們創建一張用戶主表+兩張用戶分表 用戶分表user0 用戶分表user1
//首先所有用戶數據入用戶主表
$sql = insert into users(a,b,c) values($a,$b,$c);
$res = $model->query($sql);
if($res){
//獲取user主表插入的最后一條sql的id
$insert_id = $model->getLastInsId();
//對剛才入庫成功的記錄的id取模 如果你是兩種用戶分表那么就%2如果是200張那么就%200
$d = $insert_id%2;
//取模之后 獲取到最后的模 任何數對2取模那么不是0就是1 任何數對200取模那么模就是0到200之間
//插入到不同的用戶分表當中去
$_sql = insert into user{$d} (a,b,c) values($a,$b,$c);
$ru = $model->query($_sql);
}
其實我們是利用了取模的形式做了一個中間件的功能，根據模的數值去往不同的 user0 還有 user1 當中插入數據，達到了分發的效果
整個過程 user 主表一定是先插入數據的，然后根據模再去往不同的分表里面插數據；
需要強調的是 user 分表里面的 user_id 主鍵一定不是自增的，一定是根據 user 主表里面的 id 來插入的，必須保證和主表里面的主鍵 id 保持一致！
需要強調的是 user 主表和 user0 user1 分表一定是字段屬性相同的直接復制即可，只是把數據分發到不同的表里面去了，這也叫水平分表！
在做 mysql 的水平分表的時候要記住，潛規則，默認的新增的時候我們插入到 user 主表然后根據取模插入到不同的分表里面去，但是刪除，修改，查看，都和主表沒關系了，主表只有在新增的時候往里面寫入數據根據 id 取模再分發到不同的分表里面去！當然主表也可以做一些其他方面的統計。
mysql 分布式之分表實戰（修改查看刪除分表數據）
上邊我們講過，修改刪除查詢的時候直接操作的是分表，不再去動主表
//偽代碼
$id = $_POST['id'];
//對主鍵id取模從而來判斷操作哪張分表
$d = $id%2;
$sql = update user{$d} set username='{$username}',age='{$age}' where id = $id;
$model->query($sql);
修改刪除也是根據主鍵 id 對其取模確定下來針對哪張分表進行修改或者刪除
但是我們刪除或者修改了那么主表里面的數據也就和分表里面的不一致了啊，如何保證主表和從表數據一致呢？
很多人會想在操作完分表之后立馬去操作主表做修改操作不得了，也行啊！但是不感覺浪費嗎？如果你學會了協程那么可以起一個協程去操作主表即可，或者起一個異步 task 任務去操作主表也可以，都是異步執行不影響程序的執行，這是非常好的做法，前提是你得懂什么是協程以及 swoole 里面的 task 異步任務，之前博客里面有講，可以去翻翻我的博客。
另外還有一種老套的方式就是利用隊列的形式，不，不，不，不，不叫隊列，redis 里面的 list, 充其量叫列表，redis5 才新增了一種新的類型 stream 類型那才是真正的隊列，是相當於乞丐版的 kafka, 利用 redis 里面的 list 類型，將修改分表的 sql 語句改成修改主表的 sql, 條件一直 id 一直 只是操作的表為主表即可，然后塞到 list 列表里面去 lpush 然后弄個定時任務 rpop 去更新主表即可！這種方法很笨哦，但是也管用！
剛開始就說了一定要結合實際的業務需求，我們上邊講到的是按照主鍵 id 進行的數據的分發到不同的分表當中，所以不管是查詢修改還是刪除都要結合主鍵 id 去確定要操作的分表才行，有一定的局限性，但是我們的實際業務就是這么設計的，所以還是那句嘮嘮叨叨的話，一定要結合自己的實際業務需求；
分表並不是最優的解決方案，並且在實際的應用當中使用不不是很廣泛，存在就有道理，主要還是看你的業務需求啦哦！
更多學習內容請訪問：
