今天的這個案例主要是正對於講解這個Mysql的橫向拆分技術：
首先我們來模擬一個場景，用戶表裏面有着一千萬的數據量的內容，這個時候我們該如何進行優化呢？
這個時候不妨試試用橫向拆分的技術來進行優化。
首先我們來看看數據庫裏面的內容：
一共有一千萬條數據信息，這個時候我們可以繼續深入：
假設有一個請求要開展用戶搜索：
SELECT * from user where username like '9990%' 消耗時間如下：
假設現在到了一個高峯時期，我們同時有上萬個在線用戶，同時要對user表進行大量的請求和訪問，那麼就會對user表造成相當巨大的壓力，這樣我們就需要對該表的壓力進行相應的分擔。
此時我們不妨可以試試橫向分表的思想來進行優化：
例如說我們使用一定的技巧：
取模分表法
首先我們可以將user表擴展爲10張：
INSERT INTO user_1 (id, username, PASSWORD, age) SELECT id,username,password,age
FROM `user` where id%10=0使用取模的思想將主表user的數據分割放在了剩餘的10張表裏面。
如：
INSERT INTO user_2 (id, username, PASSWORD, age)SELECT id,username,password,age FROM `user` where id%10=1
INSERT INTO user_3 (id, username, PASSWORD, age)SELECT id,username,password,age FROM `user` where id%10=2就這樣一步步地將主表（user）裏面的數據拆分存儲在不同的從表（user_1,user_2..）裏面去
同理，我們對十張從表進行數據插入操作
這樣的話，一張表的壓力就會被縮小了十倍了。（暫時不考慮數據訪問的冷熱性）那麼這個時候我們進行搜索的時候就可以通過id的範圍來進行分表查詢了。
1-10號user表裏面的數據可以根據id來確定查詢的範圍大小。
下邊就是一個結合mybatis的查詢案例了（一千萬數據起步）：
其實關於sql部分的查詢內容基本如下所示：
在我們的sql設計部分裏面，有一個table_index的設置，這個table_index設置可以通過相應的id來進行區分:
然後我開啓dubbo服務之後，我們使用swagger遠程調用這個rpc接口之後即
進行測試了：
相應的sql內容如下所示：
這樣子的設計就能夠較好地減輕對於數據表的壓力了。