[轉貼]SQLSERVER的兼容級別

原帖地址：http://www.javashuo.com/article/p-oealffqi-nc.html

ALTER DATABASE (Transact-SQL) 兼容級別

https://docs.microsoft.com/zh-cn/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-2017

適用對象：SQL Server（從 2008 版開始）Azure SQL 數據庫Azure SQL 數據倉庫並行數據倉庫

將某些數據庫行爲設置爲與指定的 SQL Server 版本兼容。 有關其餘 ALTER DATABASE 選項，請參閱 ALTER DATABASE (Transact-SQL)。

有關語法約定的詳細信息，請參閱 Transact-SQL 語法約定。

語法

複製

ALTER DATABASE database_name   
SET COMPATIBILITY_LEVEL = { 150 | 140 | 130 | 120 | 110 | 100 | 90 } 

參數

database_name
要修改的數據庫的名稱。

COMPATIBILITY_LEVEL { 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }
要使數據庫與之兼容的 SQL Server 版本。 能夠配置如下兼容級別值（並不是全部版本都支持全部以上列出的兼容級別）：

Product	數據庫引擎版本	兼容級別指定	支持的兼容級別值
SQL Server 2019 預覽	15	150	150、140、130、120、1十、100
SQL Server 2017 (14.x)	14	140	140、130、120、1十、100
Azure SQL Database 邏輯服務器	12	130	150、140、130、120、1十、100
Azure SQL Database 託管實例	12	130	150、140、130、120、1十、100
SQL Server 2016 (13.x)	13	130	130、120、1十、100
SQL Server 2014 (12.x)	12	120	120、1十、100
SQL Server 2012 (11.x)	11	110	1十、100、90
SQL Server 2008 R2	10.5	100	100、90、80
SQL Server 2008	10	100	100、90、80
SQL Server 2005	9	90	90、80
SQL Server 2000	8	80	80

 備註

從 2018 年 1 月起，在 Azure SQL Database 中，新建立的數據庫的默認兼容性級別爲 140。 咱們不會更新現有數據庫的數據庫兼容性級別。 這是由客戶自行決定的。 不過，強烈建議客戶計劃轉到最新的兼容性級別，以便利用最新的改進。

若是想要對整個數據庫利用數據庫兼容性級別 140，但有理由優先選擇映射到數據庫兼容性級別 110 的 SQL Server 2012 (11.x) 的基數估計模型，請參閱 ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)，尤爲是其關鍵字 LEGACY_CARDINALITY_ESTIMATION = ON。

有關如何評估 Azure SQL Database上兩個兼容級別之間最重要查詢的性能差別的詳細信息，請參閱 Improved Query Performance with Compatibility Level 130 in Azure SQL Database（在 Azure SQL 數據庫中使用兼容級別 130 提升了查詢性能）。 注意，本文是指兼容性級別 130 和SQL Server，但一樣的方法也適用於轉到 140 的 SQL Server 和 Azure SQL Database。

執行如下查詢可肯定鏈接到的 數據庫引擎的版本。

SQL複製

SELECT SERVERPROPERTY('ProductVersion'); 

 備註

Azure SQL Database上並不支持全部功能（因兼容級別而異）。

若要肯定當前兼容級別，請查詢 sys.databases (Transact-SQL) 的 compatibility_level 列。

SQL複製

SELECT name, compatibility_level FROM sys.databases; 

Remarks

對於全部 SQL Server 安裝，默認兼容級別都設置爲 數據庫引擎的版本。 除非數據庫具備更低的兼容級別，不然數據庫會設置爲此級別。 在將數據庫從 SQL Server 的任何早期版本進行升級時，若是數據庫至少是該 SQL Server 實例所容許的最低級別，則它會保留現有兼容性級別。 升級兼容性級別低於容許級別的數據庫會將數據庫自動設置爲容許的最低兼容性級別。 這既適用於系統數據庫也適用於用戶數據庫。

附加或還原數據庫時以及就地升級後，SQL Server 2017 (14.x) 應出現如下行爲：

• 若是升級前用戶數據庫的兼容級別爲 100 或更高，升級後將保持相應級別。
• 若是升級前用戶數據庫的兼容級別爲 90，則在升級後的數據庫中，兼容級別將設置爲 100，該級別爲 SQL Server 2017 (14.x) 支持的最低兼容級別。
• 升級後，tempdb、model、msdb 和 Resource 數據庫的兼容性級別將設置爲當前兼容性級別。
• master 系統數據庫保留它在升級以前的兼容性級別。

使用 ALTER DATABASE 更改數據庫的兼容性級別。 當發出 USE <database> 命令或使用該數據庫做爲默認數據庫上下文來處理新登陸時，數據庫的新兼容性級別設置會生效。
若要查看數據庫的當前兼容級別，請查詢 sys.databases 目錄視圖中的 compatibility_level 列。

 備註

在早期版本 SQL Server 中建立並已升級到 SQL Server 2016 (13.x) RTM 或 Service Pack 1 的分發數據庫採用兼容性級別 90，其餘數據庫不支持該級別。 這並不影響複製功能。 升級到更高版本的服務包和 SQL Server 版本將致使分發數據庫的兼容性級別增長到可與主數據庫匹配。

兼容性級別和 SQL Server 升級

數據庫兼容性級別是一個重要的工具，可經過容許升級 SQL Server 數據庫引擎，同時經過維持相同的升級前數據庫兼容性級別保持鏈接應用程序功能狀態，從而幫助實現數據庫現代化。 只要應用程序不須要利用僅在更高數據庫兼容性級別中可用的加強功能，它就是升級 SQL Server 數據庫引擎 和維護以前的數據庫兼容性級別的有效方法。 有關利用兼容性級別獲取後向兼容性的詳細信息，請參閱後文的利用兼容性級別得到後向兼容性。

對於新的開發工做，或當現有應用程序須要使用新功能以及查詢優化器空間中完成的性能改進時，計劃將數據庫兼容性級別升級到 SQL Server 中可用的最新級別，並驗證應用程序可與該兼容性級別一塊兒使用。 有關升級數據庫兼容性級別的更多詳細信息，請參閱後文的升級數據庫兼容性級別的最佳作法。

 提示

若是在給定 SQL Server 版本上測試和驗證應用程序，則應用程序在該 SQL Server 版本本機數據庫兼容性級別上隱式測試和驗證。

所以，在使用對應於已測試 SQL Server 版本的數據庫兼容性級別時，數據庫兼容性級別可爲現有應用程序提供簡易的認證途徑。

有關兼容性級別之間的差別的詳細信息，請參閱後文相應的部分。

若要將 SQL Server 數據庫引擎 升級到最新版，同時將數據庫兼容性級別維持在升級前的級別並維持其可支持性狀態，建議在數據庫中使用 Microsoft 數據遷移助手工具 (DMA) 對應用程序代碼執行靜態函數外圍應用驗證。 DMA 工具輸出中沒有關於缺失或不兼容功能的錯誤，可保護應用程序免受新目標版本上的任何功能迴歸影響。 有關 DMA 工具的詳細信息，請參閱此處。

 備註

DMA 支持數據庫兼容性級別 100 及更高級別。 排除 SQL Server 2005 做爲源版本。

 重要

Microsoft 建議執行一些最小測試來驗證更新是否成功，同時維持以前的數據庫兼容性級別。 應該肯定適用於本身的應用程序和場景的最小測試。

 備註

Microsoft 在下列狀況下提供查詢計劃形狀保護：

• 新版 SQL Server（目標）在至關於以前 SQL Server 版本（源）運行的硬件上運行。
• 目標 SQL Server 和源 SQL Server 均使用同一支持的數據庫兼容性級別。

上述狀況下發生的任何查詢計劃形狀迴歸（與源 SQL Server 相比）將獲得解決。 若是出現這種狀況，請與 Microsoft 客戶支持服務部門聯繫。

利用兼容性級別得到向後兼容

數據庫兼容性級別設置隻影響指定數據庫的行爲，而不影響整個服務器的行爲。 數據庫兼容性級別只實現與 SQL Server 的早期版本保持部分後向兼容。

 提示

由於數據庫兼容級別是數據庫級設置，因此在較新的 SQL Server 數據庫引擎 上運行但使用較舊的數據庫兼容級別的應用程序仍可利用服務器級加強功能，無需對應用程序進行任何更改。

其中包括豐富的監控和故障排除改進，並提供新的系統動態管理視圖和擴展事件。 此外，還提高了可伸縮性，例如，提供自動 Soft-NUMA。

從兼容性模式 130 開始，任何影響功能的新查詢計劃都有意僅添加到新兼容性級別中。 這樣作是爲了在因爲查詢計劃更改致使性能下降而引起的升級過程當中儘可能減小風險。
從應用程序的角度來看，目標仍應在某個時間點升級到最新兼容性級別以便繼承某些新功能，以及在查詢優化器空間中完成的性能改進，不過是採用可控方式實現此目標。 經過將較低兼容性級別用做更安全的遷移輔助工具，可解決相關兼容性級別設置控制的行爲之間存在的版本差別問題。 有關更多詳細信息，包括升級數據庫兼容性級別的建議工做流，請參閱後文的升級數據庫兼容性級別的最佳作法。

 重要

給定 SQL Server 版本中引入的廢止功能不受兼容級別保護。 這指的是從 SQL Server 數據庫引擎中刪除的功能。

例如，FASTFIRSTROW 提示在 SQL Server 2012 (11.x) 中廢止，並替換爲 OPTION (FAST n ) 提示。 將數據庫兼容級別設置爲 110 不會恢復廢止的提示。 有關廢止功能的詳細信息，請參閱 SQL Server 2016 中廢止的數據庫引擎功能、SQL Server 2014 中廢止的數據庫引擎功能、SQL Server 2012 中廢止的數據庫引擎功能和 SQL Server 2008 中廢止的數據庫引擎功能。

 重要

給定 SQL Server版 本中引入的重大更改可能不受兼容級別保護。 這指的是 SQL Server 數據庫引擎 版本之間的行爲變動。 Transact-SQL 行爲一般受兼容級別保護。 可是，已更改或刪除的系統對象不受兼容級別保護。

受兼容級別保護的一個重大更改示例是從 datetime 到 datetime2 數據類型的隱式轉換。 在數據庫兼容級別 130 如下，經過考慮致使不一樣轉換值的毫秒小數部分，這些轉換顯得更加準確。 若要還原之前的轉換行爲，請將數據庫兼容級別設置爲 120 或更低。

兼容級別不保護的重大更改示例有：

• 系統對象中更改了列名。 在 SQL Server 2012 (11.x) 中，sys.dm_os_sys_info 中的列 single_pages_kb 已重命名爲 pages_kb。 不管兼容級別如何，查詢 SELECT single_pages_kb FROM sys.dm_os_sys_info 都會生成錯誤 207（列名無效）。
• 刪除了系統對象。 在 SQL Server 2012 (11.x) 中，sp_dboption 已刪除。 不管兼容級別如何，語句 EXEC sp_dboption 'AdventureWorks2016CTP3', 'autoshrink', 'FALSE'; 都會生成錯誤 2812（找不到存儲過程「sp_dboption」）。

有關重大更改的詳細信息，請參閱 SQL Server 2017 中數據庫引擎功能的重大更改、SQL Server 2016 中數據庫引擎功能的重大更改SQL Server 2014 中數據庫引擎功能的重大更改、SQL Server 2012 中數據庫引擎功能的重大更改和 SQL Server 2008 中數據庫引擎功能的重大更改。

升級數據庫兼容性級別的最佳作法

有關用於升級兼容級別的建議工做流，請參閱更改數據庫兼容性模式和使用查詢存儲。

兼容性級別和存儲過程

執行某一存儲過程時，該存儲過程將使用定義它的數據庫的當前兼容性級別。 在更改某一數據庫的兼容性設置時，該數據庫的全部存儲過程都將隨之自動從新編寫。

兼容性級別 140 和 150 的區別

此部分介紹了隨兼容性級別 150 一塊兒引入的新行爲。

對於 Azure SQL Database 和 SQL Server 2019 預覽，數據庫兼容性級別 150 目前是我的預覽版。 除了數據庫兼容性級別 140 中引入的改進以外，此數據庫兼容性級別還將與下一代查詢處理改進相關聯。

有關數據庫兼容性級別 150 中啓用的查詢處理功能的詳細信息，請參閱 SQL Server 2019 中的新增功能。

兼容級別 130 與兼容級別 140 之間的差別

本節介紹隨兼容級別 140 引入的新行爲。

兼容級別設置爲 130 或更低	兼容級別設置爲 140
引用多語句表值函數的語句的基數估計使用固定行猜想。	引用多語句表值函數的符合條件語句的基數估計會使用函數輸出的實際基數。 這經過多語句表值函數的交錯執行來實現。
請求會致使溢出到磁盤的不充足內存授予大小的批處理模式查詢可能會繼續對連續執行產生問題。	請求會致使溢出到磁盤的不充足內存授予大小的批處理模式查詢可能會提升連續執行的性能。 這經過在對批處理模式運算符發生溢出時，會更新緩存計劃內存授予大小的批處理模式內存授予反饋來實現。
請求會致使併發問題的過多內存授予大小的批處理模式查詢可能會繼續對連續執行產生問題。	請求會致使併發問題的過多內存授予大小的批處理模式查詢可能會改進連續執行的併發性。 這經過在最初請求了過多量時，會更新緩存計劃內存授予大小的批處理模式內存授予反饋來實現。
包含聯接運算符的批處理模式查詢有資格使用三種物理聯接算法，包括嵌套循環、哈希聯接和合並聯接。若是基數估計對於聯接輸入不正確，則可能會選擇不適當的聯接算法。 若是發生這種狀況，則性能會下降，而且不適當的聯接算法會保持使用，直到緩存計劃進行從新編譯。	有一個名爲自適應聯接的其餘聯接運算符。 若是基數估計對於外部生成聯接輸入不正確，則可能會選擇不適當的聯接算法。 若是發生這種狀況，而且語句有資格進行自適應聯接，則會將嵌套循環用於較小聯接輸入，將哈希聯接動態用於較大聯接輸入，而無需從新編譯。
引用列存儲索引的普通計劃沒有資格進行批處理模式執行。	引用列存儲索引的普通計劃會被放棄，以便支持有條件進行批處理模式執行的計劃。
sp_execute_external_script UDX 運算符只能在行模式下運行。	sp_execute_external_script UDX 運算符有資格進行批處理模式執行。
多語句表值函數 (TVF) 沒有交錯執行	用於改進計劃質量的多語句 TVF 交錯執行。

SQL Server 2017 以前的早期 SQL Server 版本中處於跟蹤標誌 4199 下的修補程序如今默認狀況下會啓用。 具備兼容性模式 140。 跟蹤標誌 4199 仍會適用於在 SQL Server 2017 以後發佈的新查詢優化器修補程序。 有關跟蹤標誌 4199 的信息，請參閱跟蹤標誌 4199。

兼容級別 120 和兼容級別 130 之間的差別

本節介紹隨兼容級別 130 引入的新行爲。

兼容級別設置爲 120 或更低	兼容級別設置爲 130
INSERT-SELECT 語句中的 INSERT 是單線程。	INSERT-SELECT 語句中的 INSERT 是多線程，或者能夠具備並行計劃。
內存優化表的查詢執行單線程。	內存優化表的查詢如今能夠具備並行計劃。
引入了 SQL 2014 基數估算器 CardinalityEstimationModelVersion="120"	基數估計模型 130 帶來了進一步基數估計 (CE) 改進（在查詢計劃中可見）。 CardinalityEstimationModelVersion="130"
列存儲索引的批處理模式與行模式更改： 具備列存儲索引的表上的排序處於行模式 開窗函數聚合在行模式（如 LAG 或 LEAD）下運行 具備多個不一樣子句的列存儲表的查詢在行模式下運行 在 MAXDOP 1 下運行或具備串行計劃的查詢在行模式下執行	列存儲索引的批處理模式與行模式更改： 具備列存儲索引的表上的排序如今處於批處理模式 開窗聚合如今在批處理模式（如 LAG 或 LEAD）下運行 具備多個不一樣子句的列存儲表的查詢在批處理模式下運行 在 MAXDOP 1 下運行或具備串行計劃的查詢在批處理模式下執行
能夠自動更新統計信息。	自動更新統計信息的邏輯對大型表更主動。 在實踐中，這應減小如下狀況：對於常常查詢新插入的行，可是未更新統計信息以包括這些值的查詢，客戶遇到性能問題。
在 SQL Server 2014 (12.x) 中，跟蹤 2371 默認狀況下會關閉。	在 SQL Server 2016 (13.x) 中，Trace 2371（跟蹤 2371）默認狀況下會打開。 跟蹤標誌 2371 告知自動統計信息更新程序在具備許多行的表中採樣更小但更智能的行子集。  一個重要改進是在採樣中包括更多最近插入的行。  另外一個改進是讓查詢在更新統計信息進程運行期間運行，而不阻塞查詢。
對於級別 120，統計信息經過單線程進程進行採樣。	對於級別 130，統計信息經過多線程進程進行採樣。
253 傳入外鍵是限制。	給定表能夠經過最多 10,000 個傳入外鍵或相似引用進行引用。 有關限制，請參閱 Create Foreign Key Relationships。
容許使用棄用的 MD二、MD四、MD五、SHA 和 SHA1 哈希算法。	只容許使用 SHA2_256 和 SHA2_512 哈希算法。
	SQL Server 2016 (13.x) 包括對某些數據類型轉換和某些不常見操做的改進。 有關詳細信息，請參閱 SQL Server 2016 improvements in handling some data types and uncommon operations（SQL Server 2016 在處理某些數據類型和不常見操做方面所作的改進）。
STRING_SPLIT 函數不可用。	STRING_SPLIT 函數在兼容性級別 130 或更高級別下可用。若是數據庫兼容性級別低於 130， SQL Server 將沒法找到並執行 STRING_SPLIT 函數。

SQL Server 2016 (13.x) 以前的早期 SQL Server 版本中處於跟蹤標誌 4199 下的修補程序如今默認狀況下會啓用。 具備兼容性模式 130。 跟蹤標誌 4199 仍會適用於在 SQL Server 2016 (13.x) 以後發佈的新查詢優化器修補程序。 若要在 SQL Database中使用較舊的查詢優化器，必須選擇兼容級別 110。有關跟蹤標誌 4199 的信息，請參閱跟蹤標誌 4199。

較低兼容性級別和級別 120 之間的差別

本節介紹隨兼容性級別 120 引入的新行爲。

兼容性級別設置爲 110 或更低	兼容性級別設置爲 120
使用舊版查詢優化器。	SQL Server 2014 (12.x) 包括對建立和優化查詢計劃的組件的顯著改進。 這個新的查詢優化器功能依賴於使用數據庫兼容性級別 120。 若要利用這些改進，應使用數據庫兼容性級別 120 開發新的數據庫應用程序。 應對從較早版本的SQL Server 中遷移的應用程序進行仔細測試，以便確認保持或改進了好的性能。 若是性能降低，能夠將數據庫兼容性級別設置爲 110 或更低，以便使用較早的查詢優化器方法。 數據庫兼容級別 120 使用針對現代數據倉庫和 OLTP 工做負荷進行優化的新基數估計器。 在由於性能問題將數據庫兼容級別設置爲 110 前，請參閱 SQL Server 2014 (12.x) 數據庫引擎中的新增功能主題的「查詢計劃」一節中的建議。
若是兼容級別低於 120，則在將 date 值轉換爲字符串值時語言設置將被忽略。 請注意，此行爲僅特定於 date 類型。 請參閱下面「示例」部分中的「示例 B」。	將 date 值轉換爲字符串值時，不忽略語言設置。
EXCEPT 子句右側的遞歸引用產生無限循環。 下面「示例」部分中的示例 C 演示此行爲。	EXCEPT 子句中的遞歸引用產生聽從 ANSI SQL 標準的錯誤。
遞歸公用表表達式 (CTE) 容許重複的列名。	遞歸 CTE 不容許列名重複。
若是更改觸發器，則啓用禁用的觸發器。	更改觸發器不更改觸發器的狀態（已啓用或已禁用）。
OUTPUT INTO 表子句忽略 IDENTITY_INSERT SETTING = OFF，並容許插入顯式值。	將 IDENTITY_INSERT 設置爲 OFF 後，不能爲表中的標識列插入顯式值。
將數據庫包含設置爲部分包含後，驗證 MERGE 語句的 OUTPUT 子句中的 $action 字段可能會返回排序規則錯誤。	MERGE 語句的 $action 子句返回的值的排序規則是數據庫排序規則而非服務器排序規則，所以不會返回排序規則衝突錯誤。
SELECT INTO 語句始終建立單線程插入操做。	SELECT INTO 語句可建立並行插入操做。 插入大量行時，並行操做可提升性能。

較低兼容性級別與級別 110 和 120 之間的差別

本節介紹隨兼容性級別 110 引入的新行爲。 此部分也適用於級別 120。

兼容性級別設置爲 100 或更低	至少爲 110 的兼容性級別設置
公共語言運行時 (CLR) 數據庫對象用 CLR 的版本 4 執行。 但會避免在 CLR 的版本 4 中引入的某些行爲更改。 有關詳細信息，請參閱 CLR 集成中的新增功能。	CLR 數據庫對象用 CLR 的版本 4 執行。
XQuery 函數 string-length 和 substring 將每一個代理項計爲兩個字符。	XQuery 函數 string-length 和 substring 將每一個代理項計爲一個字符。
在遞歸公用表表達式 (CTE) 查詢中容許 PIVOT。 然而，當每一個分組有多個行時，該查詢返回不正確的結果。	在遞歸公用表表達式 (CTE) 查詢中不容許 PIVOT。 將返回錯誤。
RC4 算法僅用於支持向後兼容性。 僅當數據庫兼容級別爲 90 或 100 時，才能使用 RC4 或 RC4_128 對新材料進行加密。 （建議不要使用。）在 SQL Server 2012 (11.x) 中，能夠經過任何兼容性級別對使用 RC4 或 RC4_128 加密的材料進行解密。	不能使用 RC4 或 RC4_128 加密新材料。 而是使用一種較新的算法，如 AES 算法之一。 在 SQL Server 2012 (11.x) 中，能夠經過任何兼容性級別對使用 RC4 或 RC4_128 加密的材料進行解密。
對 time 和 datetime2 數據類型的 CAST 和 CONVERT 操做的默認樣式爲 121，當在計算列表達式中使用這些類型時除外。 對於計算列，默認樣式爲 0。 當建立用於涉及自動參數化的查詢中或約束定義中的計算列時，此行爲會影響計算列。 下面「示例」部分中的示例 D 顯示樣式 0 與 121 之間的差別。 它並不演示上面所述的行爲。 有關日期和時間樣式的詳細信息，請參閱 CAST 和 CONVERT (Transact SQL)。	兼容級別爲 110 時，對 time 和 datetime2 數據類型的 CAST 和 CONVERT 操做的默認樣式始終爲 121。 若是您的查詢依賴舊行爲，請使用低於 110 的兼容性級別或在受影響的查詢中顯式指定 0 樣式。 將數據庫升級到兼容性級別 110 將不更改已存儲到磁盤的用戶數據。 您必須相應手動更正此數據。 例如，若是使用了 SELECT INTO 來從包含上述計算列表達式的源建立表，將存儲數據（使用樣式 0）而非存儲計算列定義自己。 您須要手動更新此數據，以匹配樣式 121。
在分區視圖中引用的遠程表的全部 smalldatetime 類型的列都將映射爲 datetime。本地表中相應的列（在選擇列表中的相同序號位置中）必須爲 datetime 類型。	在分區視圖中引用的遠程表的全部 smalldatetime 類型的列都將映射爲 smalldatetime。 本地表中相應的列（在選擇列表中的相同序號位置中）必須爲 smalldatetime 類型。 在升級到 110 後，分佈式分區視圖將因爲數據類型不匹配而失敗。 能夠經過將針對遠程表的數據類型更改成 datetime 或者將本地數據庫的兼容級別設置爲 100 或更低，解決上述問題。
SOUNDEX 函數實現如下規則： 1) 當分隔兩個具備相同 SOUNDEX 代碼的輔音時，將忽略大寫 H 或大寫 W。 2) 若是 character_expression 的前 2 個字符具備相同的 SOUNDEX 代碼，則將包含這兩個字符。 若是一組並行輔音具備相同的 SOUNDEX代碼，則將不包含它們，第一個輔音除外。	SOUNDEX 函數實現如下規則： 1) 若是大寫 H 或大寫 W 分隔具備相同 SOUNDEX 代碼的兩個輔音，則將忽略右側的輔音 2) 若是一組並行輔音具備相同的 SOUNDEX 代碼，則將不包含它們，第一個輔音除外。 其餘規則可能致使由 SOUNDEX 函數計算的值不一樣於在更低數據庫兼容級別時計算的值。 在升級到兼容級別 110 後，可能須要從新生成使用 SOUNDEX 函數的索引、堆或 CHECK 約束。 有關詳細信息，請參閱 SOUNDEX (Transact-SQL)。

兼容性級別 90 和兼容性級別 100 之間的差別

本節介紹隨兼容性級別 100 引入的新行爲。

兼容性級別設置爲 90	兼容性級別設置爲 100	影響的可能性
對於多語句表值函數，在建立它們時，不管會話級別設置如何，QUOTED_IDENTIFER 設置始終爲 ON。	在建立多語句表值函數時，會遵循 QUOTED IDENTIFIER 會話設置。	Medium
在建立或更改分區函數時，會評估函數中的 datetime 和 smalldatetime 文字，並假定語言設置爲 US_English。	使用當前語言設置來評估該分區函數中的 datetime 和 smalldatetime 文字。	Medium
容許在 INSERT 和 SELECT INTO 語句中使用（並忽略）FOR BROWSE 子句。	不容許在 INSERT 和 SELECT INTO 語句中使用 FOR BROWSE 子句。	Medium
OUTPUT 子句中容許使用全文謂詞。	OUTPUT 子句中不容許使用全文謂詞。	Low
CREATE FULLTEXT STOPLIST、ALTER FULLTEXT STOPLIST和 DROP FULLTEXT STOPLIST不受支持。 系統非索引字表自動與新的全文檢索相關聯。	CREATE FULLTEXT STOPLIST、ALTER FULLTEXT STOPLIST 和 DROP FULLTEXT STOPLIST 受支持。	Low
MERGE 不做爲保留關鍵字強制應用。	MERGE 是徹底保留的關鍵字。 在 100 和 90 兼容級別下，都支持 MERGE 語句。	Low
使用 INSERT 語句的 <dml_table_source> 參數會引起語法錯誤。	您能夠捕獲嵌套的 INSERT、UPDATE、DELETE 或 MERGE 語句中 OUTPUT 子句的結果，而後將這些結果插入目標表或視圖。 這經過使用 INSERT 語句的 <dml_table_source> 參數來實現。	Low
除非指定 NOINDEX，不然 DBCC CHECKDB 或 DBCC CHECKTABLE 將對單個表或索引視圖及其全部非彙集索引和 XML 索引同時執行物理和邏輯一致性檢查。 不支持空間索引。	除非指定 NOINDEX，不然 DBCC CHECKDB 或 DBCC CHECKTABLE 將對單個表及其全部非彙集索引同時執行物理和邏輯一致性檢查。 可是，在默認狀況下，僅對 XML 索引、空間索引和索引視圖執行物理一致性檢查。 若是指定了 WITH EXTENDED_LOGICAL_CHECKS，則將對索引視圖、XML 索引和空間索引（若是存在）執行邏輯檢查。 默認狀況下，先執行物理一致性檢查，而後執行邏輯一致性檢查。 若是還指定了 NOINDEX，則僅執行邏輯檢查。	Low
若是將 OUTPUT 子句和數據操做語言 (DML) 語句一塊兒使用，而且在語句執行過程當中發生運行時錯誤，則會終止並回滾整個事務。	若是將 OUTPUT 子句和數據操做語言 (DML) 語句一塊兒使用，而且在語句執行過程當中發生運行時錯誤，則行爲取決於 SET XACT_ABORT 設置。 若是 SET XACT_ABORT設置爲 OFF，則由使用 OUTPUT 子句的 DML 語句所生成的語句停止錯誤將終止該語句，但批處理的執行仍會繼續，而且不會回滾事務。 若是 SET XACT_ABORT 設置爲 ON，則由使用 OUTPUT 子句的 DML 語句所生成的所有運行時錯誤都將終止批處理，並回滾事務。	Low
CUBE 和 ROLLUP 不做爲保留關鍵字強制應用。	CUBE 和 ROLLUP 是 GROUP BY 子句中的保留關鍵字。	Low
對 XML anyType 類型的元素應用嚴格驗證。	對 anyType 類型的元素應用寬鬆驗證。 有關詳細信息，請參閱通配符組成部分和內容驗證。	Low
數據操做語言語句不能查詢或修改特殊屬性 xsi:nil 和 xsi:type。 這意味着 /e/@xsi:nil 失敗，同時 /e/@* 忽略 xsi:nil 和 xsi:type 屬性。 可是，/e 返回 xsi:nil 和 xsi:type 屬性，以保持與 SELECT xmlCol 的一致性，即便 xsi:nil = "false"也是如此。	特殊屬性 xsi:nil 和 xsi:type 做爲常規屬性存儲，不能查詢和修改。 例如，執行查詢 SELECT x.query('a/b/@*') 會返回包括 xsi: nil 和 xsi: type 在內的全部屬性。 若要在查詢中排除這些類型，請用 @*[namespace-uri(.) != "insert xsi namespace uri" 替換 @*，而不是用 (local-name(.) = "type" 或 local-name(.) ="nil". 來替換	Low
用於將 XML 常量字符串值轉換爲SQL Server datetime 類型的用戶定義函數被標記爲肯定的。	用於將 XML 常量字符串值轉換爲 SQL Server datetime 類型的用戶定義函數被標記爲不肯定的。	Low
不徹底支持 XML 聯合和列表類型。	徹底支持聯合和列表類型，包括如下功能： 列表的聯合 聯合的聯合 原子類型的列表 聯合的列表	Low
當視圖或內聯表值函數中包含 xQuery 方法時，不對該方法所需的 SET 選項進行驗證。	當視圖或內聯表值函數中包含 xQuery 方法時，對該方法所需的 SET 選項進行驗證。 若是該方法的 SET 選項設置不正確，將引起一個錯誤。	Low
包含行尾字符（回車符和換行符）的 XML 屬性值不根據 XML 標準進行規範化。 即返回回車符和換行符，而不是單個換行符。	包含行尾字符（回車符和換行符）的 XML 屬性值會根據 XML 標準進行規範化。 也就是說，外部已分析實體（包括文檔實體）中的全部換行符都會在輸入時進行規範化，方法是將兩字符序列 #xD #xA 和後面沒有跟 #xA 的全部 #xD 都轉換爲單個 #xA 字符。 使用屬性來傳輸包含行尾字符的字符串值的應用程序接收到的這些字符將和提交時有所不一樣。 若要避免規範化過程，請使用 XML 數字字符實體對全部行尾字符進行編碼。	Low
ROWGUIDCOL 和 IDENTITY列屬性可能錯誤地命名爲約束。例如，CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY)語句能夠執行，但約束名不會保留，也沒法讓用戶訪問。	ROWGUIDCOL 和 IDENTITY 列屬性不能命名爲約束。返回錯誤 156。	Low
使用雙向賦值（如 UPDATE T1 SET @v = column_name = <expression>）來更新列會產生意外後果，由於在語句執行過程當中，能夠在其餘子句（如 WHER 和 ON 子句）中使用變量的實時值，而不是使用語句起始值。 這會致使謂詞的含義沒法預測地逐行變化。 只有在兼容性級別設置爲 90 時，此行爲才適用。	使用雙向賦值來更新列會產生預期的結果，由於在語句執行過程當中，只會訪問列的語句起始值。	Low
請參閱下面「示例」部分中的「示例 E」。	請參閱下面「示例」部分中的「示例 F」。	Low
ODBC 函數 {fn CONVERT()} 使用語言的默認日期格式。 對於有些語言，默認格式爲 YDM，這會致使在將 CONVERT() 與要求使用 YMD 格式的其餘函數（如 {fn CURDATE()}）結合使用時出現轉換錯誤。	在轉換爲 ODBC 數據類型 SQL_TIMESTAMP、SQL_DATE、SQL_TIME、SQLDATE、SQL_TYPE_TIME 和 SQL_TYPE_TIMESTAMP 時，ODBC 函數 {fn CONVERT()} 使用樣式 121（一種獨立於語言的 YMD 格式）。	Low
日期時間內部函數（如 DATEPART）不須要字符串輸入值，便可成爲有效的日期時間文字。 例如，SELECT DATEPART (year, '2007/05-30')會編譯成功。	日期時間內部函數（如 DATEPART）須要字符串輸入值，才能成爲有效的日期時間文字。 在使用無效的日期時間文字時，會返回錯誤 241。	Low

保留關鍵字

兼容性設置還肯定了 數據庫引擎所保留的關鍵字。 下表顯示了每一個兼容性級別所引入的保留關鍵字。

兼容性級別設置	保留關鍵字
130	待定。
120	無。
110	WITHIN GROUP、TRY_CONVERT、SEMANTICKEYPHRASETABLE、SEMANTICSIMILARITYDETAILSTABLE、SEMANTICSIMILARITYTABLE
100	CUBE、MERGE、ROLLUP
90	EXTERNAL、PIVOT、UNPIVOT、REVERT、TABLESAMPLE

在給定兼容性級別，保留關鍵字包括在該級別或較低級別引入的全部關鍵字。 例如，對於兼容性級別爲 110 的應用程序，將保留上表列出的全部關鍵字。 在較低的兼容性級別中，級別 100 的關鍵字仍保留有效的對象名，但與這些關鍵字相對應的級別 110 的語言功能將不可用。

一旦引入，關鍵字便會保持爲保留關鍵字。 例如，在兼容性級別 90 中引入的保留關鍵字 PIVOT 在級別 100、110 和 120 中也被保留。

若是某一應用程序使用對其保留級別而言是關鍵字的標識符，則該應用程序將失敗。 若要解決這一問題，請用方括號 ([]) 或引號 ("") 括起該標識符；例如，若要將使用標識符 EXTERNAL 的應用程序升級爲兼容級別 90，能夠將該標識符更改成 [EXTERNAL] 或 "EXTERNAL"。

有關詳細信息，請參閱保留關鍵字 (Transact-SQL) 。

Permissions

須要對數據庫擁有 ALTER 權限。

示例

A. 更改兼容性級別

如下示例將 AdventureWorks2012 數據庫的兼容級別更改成 110, SQL Server 2012 (11.x)。

SQL複製

ALTER DATABASE AdventureWorks2012 SET COMPATIBILITY_LEVEL = 110; GO 

如下示例返回當前數據庫的兼容級別。

SQL複製

SELECT name, compatibility_level FROM sys.databases WHERE name = db_name(); 

B. 忽略 SET LANGUAGE 語句（除非低於兼容級別 120）

只有兼容級別低於 120 時，如下查詢纔會忽略 SET LANGUAGE 語句。

SQL複製

SET DATEFORMAT dmy; DECLARE @t2 date = '12/5/2011' ; SET LANGUAGE dutch; SELECT CONVERT(varchar(11), @t2, 106); -- Results when the compatibility level is less than 120. 12 May 2011 -- Results when the compatibility level is set to 120). 12 mei 2011 

C.

對於 110 或更低的兼容級別設置，EXCEPT 子句右側的遞歸引用產生無限循環。

SQL複製

WITH   
cte AS (SELECT * FROM (VALUES (1),(2),(3)) v (a)), r AS (SELECT a FROM Table1 UNION ALL (SELECT a FROM Table1 EXCEPT SELECT a FROM r) ) SELECT a FROM r; 

D.

此示例顯示樣式 0 和 121 之間的差別。 有關日期和時間樣式的詳細信息，請參閱 CAST 和 CONVERT (Transact SQL)。

SQL複製

CREATE TABLE t1 (c1 time(7), c2 datetime2); INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE()); SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0 ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121 ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0 ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121 FROM t1; -- Returns values such as the following. TimeStyle0 TimeStyle121 Datetime2Style0 Datetime2Style121 ---------------- ---------------- -------------------- -------------------------- 3:15PM 15:15:35.8100000 Jun 7 2011 3:15PM 2011-06-07 15:15:35.8130000 

E.

在包含頂級 UNION 運算符的語句中，容許使用變量賦值，但會返回意外的結果。 例如，在如下語句中，未來自兩個表的聯合的 @v 列的值賦給局部變量 BusinessEntityID。 按照定義，若是 SELECT 語句返回多個值，則將返回的最後一個值賦給變量。 在這種狀況下，會正確地將最後一個值賦給變量，但還會返回 SELECT UNION 語句的結果集。

SQL複製

ALTER DATABASE AdventureWorks2012 SET compatibility_level = 110; GO USE AdventureWorks2012; GO DECLARE @v int; SELECT @v = BusinessEntityID FROM HumanResources.Employee UNION ALL SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress; SELECT @v; 

F.

在包含頂級 UNION 運算符的語句中不容許變量賦值。 返回錯誤 10734。 若要糾正該錯誤，請重寫查詢，以下例所示。

SQL複製

DECLARE @v int; SELECT @v = BusinessEntityID FROM (SELECT BusinessEntityID FROM HumanResources.Employee UNION ALL SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test; SELECT @v; 

另請參閱

ALTER DATABASE (Transact-SQL) 
保留關鍵字 (Transact-SQL) 
CREATE DATABASE (SQL Server Transact-SQL) 
DATABASEPROPERTYEX (Transact-SQL) 
sys.databases (Transact-SQL) 
sys.database_files (Transact-SQL)
查看或更改數據庫的兼容級別