03.SQLServer性能優化之---存儲優化系列

彙總篇： http://www.cnblogs.com/dunitian/p/4822808.html#tsql 概  述： http://www.cnblogs.com/dunitian/p/6041323.html#com

以下内容皆為個人摸索，沒有人專門指導（公司不給力啊！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 (我還沒研究，改天要是可以就發篇文章)

官網：

http://mycat.io/ 文檔： https://github.com/MyCATApache/Mycat-doc https://github.com/MyCATApache/Mycat-Server

04.SQLServer性能優化之---讀寫分離&資料同步 

http://www.cnblogs.com/dunitian/p/6041758.html

作者：

毒逆天

出處：

https://www.cnblogs.com/dotnetcrazy

打賞：

18i4JpL6g54yAPAefdtgqwRrZ43YJwAV5z

本文版權歸作者和部落格園共有。歡迎轉載，但必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接！