四大方面講述SQL2005與SQL2000的改進

本文從資料庫設計、開發、DBA管理等四個方面敘述了SQL2005與SQL2000兩個版本間的改進。

一、資料庫設計方面

1、欄位型別。

varchar(max) varchar(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後，如果在現有的分割槽表上建立沒有顯式宣告的聚集索引時，分割槽表會自動變為非分割槽表。這一點很讓我納悶。如果你覺得我的非分割槽索引無法對起子分割槽。

分割槽表效率問題肯定是大家關心的問題。在我的試驗中，如果按照分割槽欄位進行的查詢（過濾）效率會高於未分割槽表的相同語句。但是如果按照非分割槽欄位進行查詢，效率會低於未分割槽表的相同語句。但是隨著資料量的增大，這種成本差距會逐漸減小，趨於相等。（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了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-369032/，如需轉載，請註明出處，否則將追究法律責任。