以下內容皆為個人摸索，沒有人專門指導（公司不給力啊！DBA和大牛都木有。。。），所以難免出錯，如有錯誤歡迎指正，小子勇於接受批評~(*^__^*) ~

水平分庫分表和垂直分庫分表，大家都經常談，我說下我的理解，看圖：

垂直分表就不用說了，基本上會SQLServer的都會。

垂直分庫就是根據業務需求來分庫，比如教育系列的，可以分為資訊，課程，使用者（學生，學校）三個資料庫。比如電商的可以分為訂單，商品，使用者（商家，消費者）三個資料庫。這邊只是舉個例子，具體的你得根據你們自己業務的實際情況來分，不是分的越多越好，最好是遇到瓶頸了再去做這些事情（這個過程才能學到很多東西）

水平分表主要就兩種方法，Hash取餘法和時間路由法。

我重點說下時間路由的方法，這種方案後期擴容和歷史資料抽離【結合列索引更勁爆哦~】比較方便。

舉個簡單的路由表：（時間你可以用傳統的格式，我這邊用的是時間軸）

這個是文章表的時間路由表，每次查詢文章的時候根據查詢的時間看看

比如我現在準備寫入資料，當前時間 2016/11/18 16:37:29 ==》1479458249

select RTableName from Route_Article where where 1479458249 between RCreateTime and REndTime

就可以知道我應該往哪個表裡面寫資料：==》Article2

同理，想查詢某個時間的資料也是可以通過路由表知道該往哪個表裡面查詢

其實企業裡面用的最多的是複合型的，比如：水平分庫分表 ，水平分庫+垂直分庫+分表

真的有了這方面的瓶頸的話水平分表一般只能緩解，並不能真正解決，畢竟還是在一臺伺服器上。單表的資料量是減少了，但是IO，連線數，頻寬之類的瓶頸並不能有多大的改善。

水平分庫分表可以把IO瓶頸解決一部分，優化效果還是很明顯的：

水平分庫+垂直分庫+分表，這個方案可以利用連結伺服器，這樣路由表就不用改了，把路由表的表名改成完整的名稱（後面會說更好的方法）

看直觀圖：[192.168.1.250].[BigValues].[dbo].[Article]

我簡單模擬一下：我PC的IP是：192.168.1.9

先在遠端資料庫稍微插點資料：2013-1-1 ~ 2015-1-1的資料，量倒是不多，200W左右

 先設定一下連結伺服器。我自己摸索的這個方法可能和網上的不太一樣，不要慌（沒辦法，我按照網上的沒成功啊+_+）

安全性裡面設定一下使用者名稱和密碼

可以了，看看吧：

 先看看效果：

這個感覺挺好的，一般情況下都是沒問題的，但是遇到資料庫名字或者表改了就蛋疼了，得改多少東西？？關鍵是不太方便，名字那麼長。。。===》so，引入了同義詞

create synonym Article for [192.168.1.250].[BigValues].[dbo].[Article]

再看看效果吧：

-----------------------------------------------------------------------------------------------------

是不是感覺特簡單，也想改革起來了？(⊙o⊙)…，其實我還是建議快到瓶頸的時候再改，不然你會很蛋疼的，現在我就簡單說幾個蛋疼的地方~PS：附帶我的解決方案

簡單說下有哪些問題：

1.全域性ID的問題，既然分表了，那麼第一件事情就是把自增長去掉，（eg：表A，ID為44，表B，ID為44，那我取44的資料時，取哪個呢？）

一開始我是用GUID的方式，一直認為這個不太好，為啥呢，我一般使用者ID或者管理員ID會用GUID，這樣Burp的暴力解猜就比較上門檻了（簡單使用：http://www.cnblogs.com/dunitian/p/5724872.html）

後來發現，GUID的主鍵基本上滿足需求，但是無序列，而且太長了，排序什麼的都各種不方便，後來就找其他方法，很多，比如時間軸，後來發現高併發下還是有重複的（畢竟已經不是單機了）最終採取了雪花演算法（https://github.com/twitter/snowflake）

2.跨庫Join

MySQL比較蛋疼，MSSQL好像沒那麼難，我是用連結伺服器+同義詞的方法解決的（上面演示的），如果有更好方案可以提點一下小子^_^

看圖：

很多時候可以參考MyCat的一些東西，跨庫查詢肯定效率沒有單機高。有時候會做一些處理來儘量避免跨庫Join

比如說表A，表B，表C...常用的全域性表我會把他們每個資料庫存一遍，這樣就方便多了（注意一下資料同步哦）

還有就是冗餘一些欄位

比如：產品表有這些欄位：商品展圖ID，展圖URL，縮略展圖URL。按理說這是不合理的，但是不這麼幹就得跨庫查詢了，適當犧牲嘛~

再比如：訂單表裡面：使用者ID，使用者名稱，店鋪ID，店鋪名，商品縮略展圖。這樣也是不合理的，但是。。。商品和訂單大家都懂的，牽扯的表太多，有點誇張了~

以後分庫的時候可以參考MyCat的ER分庫 （相關聯的一起分）

3.跨庫排序、聚合等

比如要求Count，那麼每個表都得單獨求一下Count，然後彙總Count。這個過程可以通過應用程式去完成，畢竟可以根據路由表來統一彙總

排序就比較蛋疼了，如果是按時間（分表字段）的還好，因為我們路由表就是按時間分表的，相對簡單。如果按照某個欄位排序的話。。。。。(⊙o⊙)…沒辦法就取每個表裡面的資料吧。

很多人總是疑惑為什麼分頁越往後面越慢（按時間不怕，我們就是按時間分表的，你去對應時間區裡面取就好了）

比如按欄位1排序，每一頁20條資料，要求取第一頁的資料==》

取第五頁的資料==》想想看，這麼搞的話，怎麼不卡？你們有更好的解決方法可以說，小子比較菜O(∩_∩)O

(⊙o⊙)…，最後說下我最近在研究的解決方案：

分散式資料庫訪問層：攜程DAL ，支援MySQL，SQLServer。支援Net，Java

Ctrip DAL支援流行的分庫分表操作，支援Java和C#，支援Mysql和MSSqlServer。使用該框架可以在有效地保護企業已有資料庫投資的同時，迅速，可靠地為企業提供資料庫訪問層的橫向擴充套件能力。

 

這個是後備方案：（下午讓朋友去問了一些MyCat的作者，他說MyCat開發的時候就沒有限定資料庫和開發語言，MySQL，SQLServer都是支援的，換個埠而已，開發語言也沒什麼限制，只要你能連線MyCat就能用）

資料庫中間元件：MyCat (我還沒研究，改天要是可以就發篇文章)