以下內容皆為個人摸索，沒有人專門指導（公司不給力啊！DBA和大牛都木有。。。），所以難免出錯，如有錯誤歡迎指正，小子勇於接受批評~(*^__^*) ~
水平分庫分表和垂直分庫分表，大家都經常談，我說下我的理解，看圖：
垂直分表就不用說了，基本上會SQLServer的都會。
垂直分庫就是根據業務需求來分庫，比如教育系列的，可以分為資訊，課程，用戶（學生，學校）三個數據庫。比如電商的可以分為訂單，商品，用戶（商家，消費者）三個數據庫。這邊只是舉個例子，具體的你得根據你們自己業務的實際情況來分，不是分的越多越好，最好是遇到瓶頸了再去做這些事情（這個過程才能學到很多東西）
水平分表主要就兩種方法，Hash取余法和時間路由法。我重點說下時間路由的方法，這種方案后期擴容和歷史數據抽離【結合列索引更勁爆哦~】比較方便。
舉個簡單的路由表：（時間你可以用傳統的格式，我這邊用的是時間軸）
這個是文章表的時間路由表，每次查詢文章的時候根據查詢的時間看看
比如我現在准備寫入數據，當前時間 2016/11/18 16:37:29 ==》1479458249
select RTableName from Route_Article where where 1479458249 between RCreateTime and REndTime
就可以知道我應該往哪個表里面寫數據：==》Article2
同理，想查詢某個時間的數據也是可以通過路由表知道該往哪個表里面查詢
水平分庫之前提了一下文件組（http://www.cnblogs.com/dunitian/p/5276431.html）后面還會有一篇文章進行擴展說明（http://www.cnblogs.com/dunitian/p/6078512.html），這邊就不說了。
其實企業里面用的最多的是復合型的，比如：水平分庫分表 ，水平分庫+垂直分庫+分表
真的有了這方面的瓶頸的話水平分表一般只能緩解，並不能真正解決，畢竟還是在一台服務器上。單表的數據量是減少了，但是IO，連接數，帶寬之類的瓶頸並不能有多大的改善。
水平分庫分表可以把IO瓶頸解決一部分，優化效果還是很明顯的：
水平分庫+垂直分庫+分表，這個方案可以利用鏈接服務器，這樣路由表就不用改了，把路由表的表名改成完整的名稱（后面會說更好的方法）
看直觀圖：[192.168.1.250].[BigValues].[dbo].[Article]
我簡單模擬一下：我PC的IP是：192.168.1.9
先在遠程數據庫稍微插點數據：2013-1-1 ~ 2015-1-1的數據，量倒是不多，200W左右
沒有跨庫查詢過的同志，可以先預習一下同義詞相關的知識：http://www.cnblogs.com/dunitian/p/6041323.html#tyc
先設置一下鏈接服務器。我自己摸索的這個方法可能和網上的不太一樣，不要慌（沒辦法，我按照網上的沒成功啊+_+）
安全性里面設置一下用戶名和密碼
可以了，看看吧：
先看看效果：
這個感覺挺好的，一般情況下都是沒問題的，但是遇到數據庫名字或者表改了就蛋疼了，得改多少東西？？關鍵是不太方便，名字那么長。。。===》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）
C#版本的國外朋友已經封裝了，大家可以去看看：https://github.com/ccollie/snowflake-net
強大的網友出來個簡化版本：http://blog.csdn.net/***/article/details/***6 （地址我就不貼了，對前輩需要最起碼的尊敬）
一開始我用的是這個版本，后來發現多線程的情況下有重復項。。。（demo：https://github.com/dunitian/TempCode/tree/master/2016-11-16/Twitter_Snowflake）
全局ID的激烈討論：https://q.cnblogs.com/q/53552/
具體實現：http://www.cnblogs.com/dunitian/p/6130543.html
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。使用該框架可以在有效地保護企業已有數據庫投資的同時，迅速，可靠地為企業提供數據庫訪問層的橫向擴展能力。
開源地址：https://github.com/ctripcorp/dal
文檔系列：https://github.com/ctripcorp/dal/wiki/
這個是后備方案：（下午讓朋友去問了一些MyCat的作者，他說MyCat開發的時候就沒有限定數據庫和開發語言，MySQL，SQLServer都是支持的，換個端口而已，開發語言也沒什么限制，只要你能連接MyCat就能用）
數據庫中間組件：MyCat (我還沒研究，改天要是可以就發篇文章)
文檔：https://github.com/MyCATApache/Mycat-doc
開源地址：https://github.com/MyCATApache/Mycat-Server
04.SQLServer性能優化之---讀寫分離&數據同步 http://www.cnblogs.com/dunitian/p/6041758.html