1.水平拆分方法
（1）範圍法（自增長唯一標識進行資料拆分）
（2）hash法（通過對資料的唯一標識進行計算取模，路由到對應的庫表）
2.水平拆分後碰到問題
1.對於只通過唯一標識進行查詢業務，很好解決，直接雜湊 唯一標識即可，但是通過非 「主屬性」 進行 查詢就有問題了。無法進行路由選擇。
3.解決方案
建立起 非主屬性 與主屬性之間的關係。產生關係對映。那麼建立一張表，這張表中 儲存了 使用者id與 使用者狀態、使用者最近活躍時間。那麼我們就可以通過查詢 「禁用」的狀態的 使用者id有哪些？就可以查詢出「近期活躍」的使用者id有哪些？然後進行正常的業務操作了。
那麼說到這個地方，那可能有童鞋會疑問，通常來說，正常人的思維不都是 以 id 查詢 name嗎？這裡為什麼用name查詢 id？合適嗎？方便嗎？那麼這個使用就可以使用 「倒排索引」的概念了。 依照之前寫的一篇文章：什麼是 es？什麼是倒排索引。那篇文章解釋了，看一下你就會回來說，誒，是這麼個道理誒。
4.線上環境如何 優雅的擴容（ps：不停服，更新？？？）
王者榮耀，刺激戰場，很火爆。相信很多人都會在不同的時間段進行玩這個遊戲。那伺服器怎麼擴容呢？隨著使用者量的激增，那麼資料庫的讀寫效能也會隨著降低，怎麼解決呢?需要擴容的話，怎麼做到使用者無感知擴容呢？相信很多老玩家肯定碰到過「王者榮耀更新公告：不停機公升級。」 」王者榮耀更新公告：停服 0:00 ~ 23:59，公升級「。那麼停服公升級，我們可以很好理解，停服公升級嘛：構建n個新的庫，結構一致，那麼將路由掃瞄進行新增這n個庫，就可以取模運算到n庫中。然後將對應的原old庫中的資料，重新取模運算，如果是其他庫的，將進行資料遷移。將老資料進行新的均衡分配。那麼再重新啟動服務，那就完成了資料庫的公升級擴容，並且解決了老資料遷移問題。
但是有個問題：停服擴容固然好用。但是不夠優雅，對於使用者角度來說，只是乙個公升級擴容，不是什麼大動作。直接停服了。那使用者體驗很差。那下面就說一下 優雅擴容的 解決方案：
舉例說明：原 2個庫，現準備增加 2個庫。
那麼原 2個庫 中有 5個使用者了。 使用者1、使用者3、使用者5 原先路由到db1; 使用者2、使用者4 原先路由到db2;
那現在 第一步；先搭建好 對應的2 個庫。建立為對應，分別建立同步關係（觸發器） db3 同步 db1 中資料； db4 同步 db2 中的資料；然後現在情況是：使用者1、使用者3、使用者5使用 db1 中的 資料， 那麼db3可以理解為從庫，保持與db1中的資料一致。 同理：db2 與 db4;
然後，修改服務的配置，將2個庫改為4個庫，重啟業務服務，那新的路由策略生效，使用者1、使用者3路由到db1; 使用者2原先路由到db2; 使用者5路由到db3; 使用者4原先路由到db4; 業務正常進行
再斷開db3對主庫的同步、斷開db4對主庫的同步。保證其他髒資料不再增漲，然後將四個庫中屬於其他庫的資料全部清空。那麼完成資料收縮操作。
完成優雅的資料庫擴容操作。其他操作也同理。
思路來自網際網路中某個大佬，用自己的語言描述了一下
分庫分表SQL優化
分庫拆表 好處 1.資料庫容量問題 2.解決效能壓力的最優選擇 原則 反正規化資料結構設計，所謂反正規化，第一要點是不用外來鍵，不允許join 操作，不允許任何需要跨越兩個表的查詢請求 第二要點是適度冗餘減少查詢請求。分庫方案 1.安全性拆分 將高安全性資料與低安全性資料分庫，這樣的好處第一是便於維...
資料庫效能優化之 分庫分表的應用
分庫分表的概念 分庫分表就是按照一定的規則，對原有的資料庫和表進行拆分，把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。隨著時間和業務的發展，資料庫中的資料量增長是不可控的，庫和表中的資料會越來越大，隨之帶來的是更高的磁碟 io 系統開銷，甚至效能上的瓶頸，而...
怎麼進行分庫分表以及資料遷移
已經明白為啥要分庫分表了，你也知道常用的分庫分表中介軟體了，你也設計好你們如何分庫分表的方案了 水平拆分 垂直拆分 分表 那問題來了，你接下來該怎麼把你那個單庫單錶的系統給遷移到分庫分表上去？友情提示 3個庫，每個庫里分了4個表，每個表要放50萬的資料量 假設你已經選擇了乙個分庫分表的資料庫中介軟體...