還有一個帖子《sqlserver的并發處理能力到底如何呀？高手都說說？》

其實這個題目是too open ended，無論大家認為它的定位在Oracle之下，還是只適合于中小型數據庫，我只想說一下它在我眼中的能力

我相信我寫完后其他數據庫愛好者就會出來噴了，Oracle的、MySQL的，畢竟這種文章跟《C#和JAVA哪家強》之類的文章是比較類似的。

我在這篇文章主要講兩個大家最care的方面：數據量、性能和功能

其實大家剛開始用數據庫最關心的莫過于OLTP場景里面的性能了還有這個數據庫系統的所能夠hold住的數據量

一、hold住大數據量

SQL Server作為一個成熟的商業數據庫，對于hold住大數據量是沒有問題的

正如上面文章提到的：Microsoft  IT  使用SQL Server來驅動 27TB的全球法定安全工具

在本人所在公司也有一些比較大的數據庫，數據庫體積大的也有7~8TB，小的幾十MB

很多人說：“SQL Server不能處理海量數據，數據量一大SQL Server就處理不了！”

我想問：“海量數據究竟有多少數據？1億？10億？100億？1TB？10TB？100TB？”

反正我天天都對著這麼多數據（上TB也有、上十億條也有），還是這樣用SQL Server管理它們。

我這里想說明一下如何比較數據量：比較數據量應該用數據庫的實際占用體積大小來比較，而不應該用單表數據量的大小來比較！

這里有一個例子：之前我們數據庫服務器里有一個表，有六個字段，都是int類型，單表數據量已經1億+了，但是數據庫的大小只有20G不到

在我眼中只是一個比較小的數據庫，雖然它的數據量比較驚人

在園友馬非碼的博客里曾經寫到一篇文章《我是如何在SQLServer中處理每天四億三千萬記錄的》，文章是非常多的推薦

但是在我眼里，文章沒有多少新意，正如我剛才說的，四億三千萬數據可能就<100G的數據，這麼多數據其實跟SQL Server是否能hold住

沒有多大關系，而是跟博主的架構能力有關系，數據庫架構無非就是 分表-》分庫-》分機房，解決CAP問題，還有就是MVCC的問題。

實際上，超大型數據庫（VLDB）跟小型數據庫管理起來是不一樣的，這里我是不管它數據量，我只管它的數據庫實際占用體積

對于管理大型數據庫里面的大表，大家第一個想法就是使用表分區來管理它，表分區從SQL Server2005開始推出到現在SQL Server2014還是使用表分區

大家會說，微軟還是沒有什么突破，還是用這麼老的表分區技術來管理大表，甚至于有時候我做了表分區，但是整個數據庫這麼大，我還是做不了完整備份。。。

貌似在大家的眼中，表分區只是作為一種提升查詢性能的工具，更直接來說，就是提升Select Query性能的利器

但是對于我們DBA來說，分區表的優勢更多的體現在管理方面

分區表的管理優勢如下：

1、壓縮單獨某個分區的數據（SQL2008）

2、按分區的統計信息（SQL2014 CREATE STATISTICS 和相關統計信息語句現在允許通過使用 INCREMENTAL 選項創建按分區的統計信息）

3、聯機重新生成某個分區的數據（SQL2014 針對聯機索引操作事件類的進度報告現在具有兩個新數據列：PartitionId 和 PartitionNumber）

4、聯機重新組織某個分區的數據（SQL2005）

5、文件組備份和段落還原(SQL2005)

6、CHECKFILEGROUP（SQL2005）

7、交換分區(刪除歷史數據或歸檔 或進行ETL)

8、鎖升級可以提升到分區鎖，而不是直接到表鎖（SQL2008）

其實只要表分區做得好，分區區間做得合理，定時維護分區表，hold住大數據量是沒有多少問題的。

前年看到一篇文章，對于關系型數據庫，如果數據庫的實際占用體積到了100TB，關系型數據庫已經無能為力了，該到Hadoop上場的時候了。

本人承認，如果你的數據庫真的有100TB，那么SQL Server可能會沒有能力handle，但是，你的數據庫真的reached 100TB，那么你們公司的數據庫架構師

是不是有責任承擔這個風險，是不是他的數據庫架構沒有做好，沒有分庫分表分機房。

我先不管關系型數據庫是否有能力handle這麼大的數據量，后來我又看了一個視頻。

視頻里面甲骨文技術產品事業部總經理吳承楊介紹了關系型數據庫和Hadoop的區別，Hadoop是處理非結構化數據的

而關系型數據庫是處理結構化數據的，兩者的側重點是不一樣，Hadoop處理的是海量非結構化數據，一般數據量PB級別

而吳承楊總經理也講到，非結構化數據通常指代的就是網頁數據，Hadoop把這些數據經過處理之后就存放進去關系型數據庫里面以便查詢

所以不能把Hadoop和關系型數據庫相提并論。

二、SQL Server的性能

性能方面，我只想談論一下IO

大家知道不管Windows還是Linux，都是 用戶程序->OS內核->存儲設備這種架構，用戶程序和OS內核之間存在一套IO接口

同樣，OS內核和存儲設備之間一樣存在一套IO接口，有異步，同步，存儲設備的Write Through和Write Back等參數

而Linux操作系統的IO行為跟Windows有很多不同之處的，兩者的文件系統的不同，兩者的IO設備驅動不一樣，IO調度模型不一樣

由于本人對Windows和Linux的IO調度沒有太深入研究，大家可以參考下面兩篇文章

Linux五種IO模型性能分析

Windows五種IO模型性能分析

其實一般不是太差的數據庫都可以達到上千的TPS，上萬的QPS，上萬的并發連接

由于本人沒有親自測試也沒有環境，就不再詳細說了

之前看過一本書，里面說Linux的IO調度模型對于使用網絡存儲的機器來講更加好，上層的一個請求，對于下層少量的網絡數據包

而Windows上層的一個IO請求會對網絡存儲發出比Linux還多的網絡數據包，好像是iSCSI協議，所以運行在Linux上的Oracle和MySQL會更勝一籌

但是可以說，SQL Server針對Windows系統做過特別優化，在TPS和QPS各方面測試中不會跟主流數據庫相差很遠，不然的話SQL Server早就從地球上消失了

三、SQL Server的功能

本人覺得SQL Server的功能做得是比較完善了，最起碼對于一個商業數據庫，其他競爭對手有的功能，SQL Server基本都有

例如限制資源使用這個功能

SQL Server的資源調控器可以針對登錄用戶限制它所使用的CPU、內存、IO資源

而MySQL的Query Throttling針對的是

限制用戶每小時的修改數據庫數據的數量

控制用戶每小時打開新連接的數量

限制有多少用戶連接MYSQL服務器

MySQL的Query Throttling偏向于查詢方面的

我這里不評論好壞，我只想說各有各的優缺點

到目前為止，我還未發現其他數據庫有的功能，SQL Server沒有的，或者本人才疏學淺，可能Oracle有的功能而SQL Server沒有的

比如：Oracle中的位圖索引，而在SQL Server中位圖過濾(Bitmap)運算符

相關文章：《SQL Server優化器特性-位圖過濾(Bitmap)》

很多時候只是大家的實現方式不一樣已而，而不代表SQL Server沒有

總結

本人做DBA的時間不長，在學校開始接觸，到畢業之后公司使用SQL Server，到現在由它來帶我進入DBA這個行業

對于SQL Server這個產品，本人是比較感激的，每天跟各位SQL Server愛好者討論如何使用它，不亦樂乎

只可惜SQL Server在中國國內市場越來越不活躍，不知道以后會不會有盡頭。

如有不對的地方，歡迎大家拍磚o(∩_∩)o