一、數據庫設計方面
1、字段類型。
varchar(max)/nvarchar(max)類型的引入大大的提高了編程的效率，可以使用字符串函數對CLOB類型進行操作，這是一個亮點。但是這就引發了對varchar和char效率討論的老問題。到底如何分配varchar的數據，是否會出現大規模的碎片？是否碎片會引發效率問題？這都是需要進一步探討的東西。

varbinary(max)代替image也讓SQL   Server的字段類型更加簡潔統一。

xml字段類型更好的解決了XML數據的操作。XQuery確實不錯，但是個人對其沒好感。（CSDN的開發者應該是相當的熟了！）

2、外鍵的級聯更能擴展
可能大部分的同行在設計OLTP系統的時候都不愿意建立外鍵，都是通過程序來控制父子數據的完整性。但是再開發調試階段和OLAP環境中，外鍵是可以建立的。新版本中加入了SET   NULL   和   SET   DEFAULT   屬性，能夠提供能好的級聯設置。

3、索引附加字段
這是一個不錯的新特性。雖然索引的附加字段沒有索引鍵值效率高，但是相對映射到數據表中效率還是提高了很多。我做過試驗，在我的實驗環境中會比映射到表中提高30%左右的效率。

4、計算字段的持久化
原來的計算字段其實和虛擬字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了計算字段的持久化，這就提高了查詢的性能，但是會加重insert和update的負擔。OLTP慎用。OLAP可以大規模使用。

5、分區表
分區表是個亮點！從分區表也能看出微軟要做大作強SQL   Server的信心。資料很多，這里不詳細說。但是重點了解的是：現在的SQL   Server2005的表，都是默認為分區表的。因為它要支持滑動窗口的這個特性。這種特性對歷史數據和實時數據的處理是很有幫助的。
但是需要注意的一點，也是我使用過程中發現的一個問題。在建立function-> schema-> table后，如果在現有的分區表上建立沒有顯式聲明的聚集索引時，分區表會自動變為非分區表。這一點很讓我納悶。如果你覺得我的非分區索引無法對起子分區，
你可以提醒我一下呀！沒有任何的提醒，直接就變成了非分區表。不知道這算不算一個bug。大家也可以試試。

分區表效率問題肯定是大家關心的問題。在我的試驗中，如果按照分區字段進行的查詢（過濾）效率會高于未分區表的相同語句。但是如果按照非分區字段進行查詢，效率會低于未分區表的相同語句。但是隨著數據量的增大，這種成本差距會逐漸減小，趨于相等。（500萬數量級只相差10%左右）

6、CLR類型

微軟對CLR作了大篇幅的宣傳，這是因為數據庫產品終于融入.net體系中。最開始我們也是狂喜，感覺對象數據庫的一些概念可以實現了。但是作了些試驗，發現使用CLR的存儲過程或函數在達到一定的閥值的時候，系統性能會呈指數級下滑！這是非常危險的！只使用幾個可能沒有問題，當一旦大規模使用會造成嚴重的系統性能問題！

其實可以做一下類比，Oracle等數據庫產品老早就支持了java編程，而且提供了java池參數作為用戶配置接口。但是現在有哪些系統大批使用了java存儲過程？！連Oracle自己的應用都不用為什么？！還不是性能有問題！否則面向對象的數據庫早就實現了！

建議使用CLR的地方一般是和應用的復雜程度或操作系統環境有很高的耦合度的場景。如你想構建復雜的算法，并且用到了大量的指針和高級數據模型。或者是要和操作系統進行Socket通訊的場景。否則建議慎重！

7、索引視圖

索引視圖2k就有。但是2005對其效率作了一些改進但是schema.viewname的作用域真是太限制了它的應用面。還有一大堆的環境參數和種種限制都讓人對它有點卻步。

8、語句和事務快照

語句級快照和事務級快照終于為SQL   Server的并發性能帶來了突破。個人感覺語句級快照大家應該應用。事務級快照，如果是高并發系統還要慎用。如果一個用戶總是被提示修改不成功要求重試時，會殺人的！

9、數據庫快照

原理很簡單，對要求長時間計算某一時間點的報表生成和防用戶操作錯誤很有幫助。但是比起Oracle10g的閃回技術還是細粒度不夠。可惜！

10、Mirror
Mirror可以算是SQL   Server的Data   guard了。但是能不能被大伙用起來就不知道了。

二、開發方面

1、Ranking函數集
其中最有名的應該是row_number了。這個終于解決了用臨時表生成序列號的歷史，而且SQL   Server2005的row_number比Oracle的更先進。因為它把Order   by集成到了一起，不用像Oracle那樣還要用子查詢進行封裝。但是大家注意一點。如下面的例子：

select   ROW_NUMBER()   OVER   (order   by   aa)
from   tbl
order   by   bb

會先執行aa的排序，然后再進行bb的排序。

可能有的朋友會抱怨集成的order   by，其實如果使用ranking函數,Order   by是少不了的。如果擔心Order   by會影響效率，可以為order   by的字段建立聚集索引，查詢計劃會忽略order   by   操作（因為本來就是排序的嘛）。

2、top
可以動態傳入參數，省卻了動態SQL的拼寫。

3、Apply
對遞歸類的樹遍歷很有幫助。

4、CTE
個人感覺這個真是太棒了！閱讀清晰，非常有時代感。

5、try/catch
代替了原來VB式的錯誤判斷。比Oracle高級不少。

6、pivot/unpivot
個人感覺沒有case直觀。而且默認的第三字段（還可能更多）作為group   by字段很容易造成新手的錯誤。

三、DBA管理方面

1、數據庫級觸發器
記得在最開始使用2k的時候就要用到這個功能，可惜2k沒有，現在有了作解決方案的朋友會很高興吧。

2、多加的系統視圖和實時系統信息

這些東西對DBA挑優非常有幫助，但是感覺粒度還是不太細。

3、優化器的改進
一直以來個人感覺SQL   Server的優化器要比Oracle的聰明。SQL2005的更是比2k聰明了不少。（有次作試驗發現有的語句在200萬級時還比50萬級的相同語句要快show_text的一些提示沒有找到解釋。一直在奇怪。）

例子：

oxJob(JobID)   jobid為聚集索引  
  oxOrder(OrderID,JobID)   兩個字段都分別建有索引  
  
  CREATE   VIEW   dbo.vw_test  
  
  AS  
  
  select   jobid,   Operationid   =   jobid   from   dbo.oxjob    
  union   all  
  select   jobid,   orderid   as   operationid   from   dbo.oxorder  
  
  查詢：  
  select   jobid   from   vw_test   where   operationid   =   @id  
       
  
  以下是測試script:  
  CREATE   TABLE   [dbo].[C]   (  
  [a]   [varchar]   (50)   NOT   NULL   ,  
     [varchar]   (50)   NULL    
  )   ON   [PRIMARY]  
  GO  
  
  CREATE   TABLE   [dbo].[D]   (  
  [a]   [varchar]   (50)   NOT   NULL   ,  
  [c]   [varchar]   (50)   NULL    
  )   ON   [PRIMARY]  
  GO  
  
  ALTER   TABLE   [dbo].[C]   WITH   NOCHECK   ADD    
  CONSTRAINT   [PK_C]   PRIMARY   KEY     CLUSTERED    
  (  
  [a]  
  )     ON   [PRIMARY]    
  GO  
  
  ALTER   TABLE   [dbo].[D]   WITH   NOCHECK   ADD    
  CONSTRAINT   [PK_D]   PRIMARY   KEY     CLUSTERED    
  (  
  [a]  
  )     ON   [PRIMARY]    
  GO  
  
    CREATE     INDEX   [IX_C_b]   ON   [dbo].[C]()   ON   [PRIMARY]  
  GO  
  
     
  
  CREATE   VIEW   dbo.vw_Test  
  AS  
  SELECT   a,b   from   C  
  union   all  
  select   a,a   from   D 

CREATE   VIEW   dbo.vw_Test  
  AS  
  SELECT   a,b   from   C  
  union   all  
  select   a,a   from   D  

4、profiler的新事件觀察
這一點很好的加強了profiler的功能。但是提到profiler提醒大家注意一點。windows2003要安裝sp1補丁才能啟動profiler。否則點擊沒有反應。

5、sqlcmd

習慣敲命令行的朋友可能會爽一些。但是功能有限。適合機器跑不動SQL   Server   Management   Studio的朋友使用。

四、遺憾

1、登陸的控制
始終遺憾SQL   Server的登陸無法分配CPU/內存占用等指標數。如果你的SQL   Server給別人分配了一個只可以讀幾個表的權限，而這個家伙瘋狂的死循環進行連接查詢，會給你的系統帶來很大的負擔。而SQL   Server如果能像Oracle一樣可以為登陸分配如：5%的cpu，10%的內存。就可以解決這個漏洞。

2、數據庫物理框架沒有變動
undo和redo都放在數據庫得transaction中，個人感覺是個敗筆。如果說我們在設計數據庫的時候考慮分多個數據庫，可能能在一定程度上避免 I/O效率問題。但是同樣會為索引視圖等應用帶來麻煩?？纯葱屑壓褪聞占壍目煺諗祿旁趖empdb中，就能感覺到目前架構的尷尬。

3、還是沒有邏輯備份
備份方面可能還是一個老大難的問題。不能單獨備份幾個表總是感覺不爽。靈活備份的問題不知道什么時候才能解決。

4、SSIS(DTS)太復雜了

SQL   Server的異構移植功能個人感覺最好了。（如果對比過SQL   Server的鏈接服務器和Oracle的透明網關的朋友會發現SQL   Server的sp_addlinkedserver(openquery)異構數據庫系列比Oracle真是強太多了。）
以前的DTS輕盈簡單。但是現在的SSIS雖然功能強大了很多，但是總是讓人感覺太麻煩?？纯凑搲性儐朣SIS的貼子就知道。做的功能太強大了，往往會有很多用戶不會用了。