在我上一篇文章中說過，mysql語句的優化有侷限性，mysql語句的優化都是圍繞著索引去優化的，那麼如果mysql中的索引也解決不了海量資料查詢慢的狀況，那麼有了水平分表與垂直分表的出現（我就是記錄一下自己的理解）
水平分表：
如上圖所示：另外三張表表結構是一樣的 只不過把資料進行分別存放在這三張表中，如果要insert 或者query 那麼都需要對id進行取餘 然後table名進行拼接，那麼就是一張完整的table_name
但是如果我需要對name進行分表呢 或者對email呢？
那麼就需要用md5進行加密 因為md5加密後是16進製制 那麼就就可以進行取餘，思路同上。
垂直分表：
為什麼需要進行垂直分表？
因為如果一張表中 有乙個大字段 而且並不是必須要展示的或者不是當前需要用的 那麼雖然沒有刻意去查詢 但是在根據id或者其他索引進行查詢的時候就會把大字段一起查出來，會嚴重影響查詢的效能，所以才有的垂直分表
詳細請看下圖：
以上就是水平分表和垂直分表的一種思路，水平有限 不足之處 請指出 謝謝
資料庫水平分表
1.前言 但資料庫資料到達千萬級別的時候，查詢如果不按索引查就會非常慢，於是這裡打算利用水平分表來優化一下查詢，提高效率 2.分表 取我當前表的某一列的前兩個數字進行二級分表，將千萬資料化分成十萬。首先執行迴圈建表 create procedure sum1 a int begin declare ...
資料庫水平分表（hash演算法）
這種預估大差不差的，論壇裡面發表帖子的表，時間長了這張表肯定很大，幾十萬，幾百萬都有可能。聊天室裡面資訊表，幾十個人在一起一聊乙個晚上，時間長了，這張表的資料肯定很大。像這樣的情況很多。所以這種能預估出來的大資料量表，我們就事先分出個n個表，這個n是多少，根據實際情況而定。以聊天資訊表為例 我事先建...
Mysql常見的水平分表
根據經驗，mysql表資料一般達到百萬級別，查詢效率會很低，容易造成表鎖，甚至堆積很多連線，直接掛掉 水平分表能夠很大程度較少這些壓力。一般在有嚴格的自增id需求上，如按照user id水平分表 table 1 user id從1 100w table 2 user id從101 200w tabl...