ALTER DATABASE (Transact-SQL) 兼容級別
2019/11/15
適用於： 是SQL Server 是Azure SQL 數據庫 否Azure Synapse Analytics (SQL DW) 否並行數據倉庫
將 Transact-SQL 和查詢處理行爲設置爲與指定的 SQL 引擎版本兼容。 有關其他 ALTER DATABASE 選項，請參閱 ALTER DATABASE。
有關語法約定的詳細信息，請參閱 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 版本。 可以配置以下兼容級別值（並非所有版本都支持所有以上列出的兼容級別）：
| Products | 數據庫引擎版本 | 默認兼容性級別標示 | 支持的兼容級別值 |
|---|---|---|---|
| SQL Server 2019 (15.x) | 15 | 150 | 150、140、130、120、110、100 |
| SQL Server 2017 (14.x) | 14 | 140 | 140、130、120、110、100 |
| Azure SQL 數據庫 單一數據庫/彈性池 | 12 | 150 | 150、140、130、120、110、100 |
| Azure SQL 數據庫 託管實例 | 12 | 150 | 150、140、130、120、110、100 |
| SQL Server 2016 (13.x) | 13 | 130 | 130、120、110、100 |
| SQL Server 2014 (12.x) | 12 | 120 | 120、110、100 |
| SQL Server 2012 (11.x) | 11 | 110 | 110、100、90 |
| SQL Server 2008 R2 | 10.5 | 100 | 100、90、80 |
| SQL Server 2008 | 10 | 100 | 100、90、80 |
| SQL Server 2005 (9.x) | 9 | 90 | 90、80 |
| SQL Server 2000 (8.x) | 8 | 80 | 80 |
! 重要
SQL Server 和 Azure SQL 數據庫的數據庫引擎版本號之間沒有可比性，它們分別是這兩項產品的內部版本號。 適用於 Azure
SQL 數據庫的數據庫引擎與 SQL Server 數據庫引擎基於相同的代碼基礎映像。 最重要的是，Azure SQL
數據庫中的數據庫引擎始終具有 SQL 數據庫引擎的最新功能。 Azure SQL 數據庫版本 12 比 SQL Server 版本 15
更新。
備註
對於所有 SQL Server 安裝，默認兼容性級別都與 數據庫引擎 的版本相關聯。 新數據庫將設置爲此級別，除非模型數據庫的兼容性級別較低 。 對於從 SQL Server 的任何早期版本附加或還原的數據庫，如果數據庫的兼容性級別是該 SQL Server 實例允許的最低級別，則將保留其現有的兼容性級別。 移動兼容性級別低於 數據庫引擎 允許級別的數據庫會自動將數據庫設置爲允許的最低兼容性級別。 這既適用於系統數據庫也適用於用戶數據庫。
附加或還原數據庫時以及就地升級後，SQL Server 2017 (14.x) 應出現以下行爲：
- 如果升級前用戶數據庫的兼容級別爲 100 或更高，升級後將保持相應級別。
- 如果升級前用戶數據庫的兼容級別爲 90，則在升級後的數據庫中，兼容級別將設置爲 100，該級別爲 SQL Server 2017 (14.x) 支持的最低兼容級別。
- 在給定的 數據庫引擎 版本中，tempdb、model、msdb 和 Resource 數據庫的兼容性級別將設置爲默認兼容性級別。
4.master 系統數據庫保留它在升級之前的兼容性級別。
使用 ALTER DATABASE 更改數據庫的兼容性級別。 當發出 USE 命令或使用該數據庫作爲默認數據庫上下文來處理新登錄時，數據庫的新兼容性級別設置會生效。 若要查看數據庫的當前兼容級別，請查詢 sys.databases 目錄視圖中的 compatibility_level 列。
備註
在早期版本 SQL Server 中創建並已升級到 SQL Server 2016 (13.x) RTM 或 Service Pack 1
的分發數據庫採用兼容性級別 90，其他數據庫不支持該級別。 這並不影響複製功能。 升級到更高版本的服務包和 SQL Server
版本將導致分發數據庫的兼容性級別增加到可與主數據庫匹配 。
備註
從 2019 年 11 月起，在 Azure SQL 數據庫 中，新創建的數據庫的默認兼容性級別爲 150 。 Microsoft
不會更新現有數據庫的數據庫兼容性級別。 這是由客戶自行決定的。 Microsoft
強烈建議客戶計劃升級到最新的兼容性級別，以充分利用最新的查詢優化改進。
若要對整個數據庫利用數據庫兼容性級別 120 或更高級別，但選擇啓用映射到數據庫兼容性級別 110 的 SQL Server 2012 (11.x)基數估計模型，請參閱 ALTER DATABASE SCOPED CONFIGURATION，尤其是它的關鍵字 LEGACY_CARDINALITY_ESTIMATION = ON 。
要詳細瞭解如何評估你最重要的查詢在 Azure SQL 數據庫 上的兩個不同兼容性級別的性能差異，請參閱 Improved Query Performance with Compatibility Level 130 in Azure SQL Database（在 Azure SQL 數據庫中使用兼容性級別 130 改進了查詢性能）。 請注意，本文介紹兼容性級別 130 和 SQL Server，但在 Azure SQL 數據庫 和 SQL Server 中也可以使用相同的方法升級到 140 或更高級別。
若要確定連接到的 數據庫引擎 版本，請執行以下查詢。
SELECT SERVERPROPERTY('ProductVersion');
備註
Azure SQL 數據庫上並不支持所有功能（因兼容級別而異）。
若要確定當前兼容級別，請查詢 sys.databases 的 compatibility_level 列。
SELECT name, compatibility_level FROM sys.databases;
兼容性級別和數據庫引擎升級
數據庫兼容性級別是一個重要的工具，可通過允許升級 SQL Server 數據庫引擎，同時通過維持相同的升級前數據庫兼容性級別保持連接應用程序功能狀態，從而幫助實現數據庫現代化。 這意味着，可以從 SQL Server 的較舊版本（例如 SQL Server 2008）升級到 SQL Server 2019 (15.x) 或 Azure SQL 數據庫（包括託管實例），而不需要更改應用程序（數據庫連接除外）。 有關詳細信息，請參閱兼容性認證。
只要應用程序不需要利用僅在更高數據庫兼容性級別中可用的增強功能，它就是升級 SQL Server 數據庫引擎 和維護之前的數據庫兼容性級別的有效方法。 有關使用兼容性級別實現後向兼容性的詳細信息，請參閱兼容性認證。
升級數據庫兼容性級別的最佳做法
有關升級兼容性級別的建議工作流，請參閱更改數據庫兼容性模式和使用查詢存儲。 此外，有關升級數據庫兼容性級別的協助體驗，請參閱使用查詢優化助手升級數據庫。
兼容性級別和存儲過程
執行某一存儲過程時，該存儲過程將使用定義它的數據庫的當前兼容性級別。 在更改某一數據庫的兼容性設置時，該數據庫的所有存儲過程都將隨之自動重新編寫。
使用兼容性級別實現後向兼容性
數據庫兼容性級別設置提供與 SQL Server 早期版本的後向兼容性，在與 Transact-SQL 和查詢優化行爲相關的方面，後向兼容性僅適用於指定的數據庫，而不是整個服務器。
從兼容性模式 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 版本中引入的中斷性變更可能不受兼容性級別保護 。 這指的是 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 ‘AdventureWorks2016’, ‘autoshrink’, ‘FALSE’; 都會生成錯誤
2812（找不到存儲過程“sp_dboption”）。 若要詳細瞭解重大更改，請參閱 SQL Server 2017
中的數據庫引擎功能重大更改、SQL Server 2016 中的數據庫引擎功能重大更改、SQL Server 2014
中的數據庫引擎功能重大更改和 SQL Server 2012 中的數據庫引擎功能重大更改。
兼容性級別之間的差異
對於所有 SQL Server 安裝，默認兼容性級別都與 數據庫引擎 版本相關聯，如此表中所示。 對於新的開發工作，請始終計劃在最新的數據庫兼容性級別上驗證應用程序。
新的 Transact-SQL 語法不受數據庫兼容性級別的限制，除非它們可以通過創建與用戶 Transact-SQL 代碼的衝突來破壞現有應用程序。 本文的後續部分介紹了這些例外，並概述了特定兼容級別之間的差異。
數據庫兼容性級別還提供與 SQL Server 早期版本的向後兼容性，因爲從任何 SQL Server 早期版本附加和還原的數據庫會保留其現有的兼容性級別（如果等於或高於允許的最低兼容性級別）。 本文的使用兼容性級別實現向後兼容性部分對此進行了介紹。
從數據庫兼容性級別 130 開始，任何影響查詢計劃的新修補程序和功能僅會添加到可用的最新兼容性級別（也稱爲默認兼容性級別）。 這樣做是爲了最大限度地減少在升級過程中由於以下原因而引發的風險：新查詢優化行爲可能引入的查詢計劃更改導致性能降低。
以下是僅添加到新版本 數據庫引擎 默認兼容性級別、影響計劃的基本更改：
- 針對跟蹤標誌 4199 下的 SQL Server 早期版本發佈的查詢優化器修補程序在 SQL Server 較新版本的默認兼容性級別中自動啓用 。 適用於： SQL Server（從 SQL Server 2016 (13.x) 開始）和 Azure SQL 數據庫。
例如，發佈 SQL Server 2016 (13.x) 時，爲使用 SQL Server 2016 (13.x) 默認兼容性級別 (130) 的數據庫自動啓用了針對 SQL Server 早期版本（相應的兼容性級別爲 100 至 120）發佈的所有查詢優化器修補程序。 只需顯式啓用後期 RTM 的查詢優化器修補程序。
備註
若要啓用查詢優化器修補程序，可以使用以下方法： 對於服務器級別，使用跟蹤標誌 4199。 對於數據庫級別，使用 ALTER DATABASE
SCOPED CONFIGURATION (Transact-SQL) 中的 QUERY_OPTIMIZER_HOTFIXES 選項。
對於查詢級別，使用 USE HINT ‘ENABLE_QUERY_OPTIMIZER_HOTFIXES’ 查詢提示。
之後，發佈 SQL Server 2017 (14.x) 時，爲使用 SQL Server 2017 (14.x) 默認兼容性級別 (140) 的數據庫自動啓用了在 SQL Server 2016 (13.x) RTM 之後發佈的所有查詢優化器修補程序。 這是一種累積行爲，還會包括所有早期版本的修補程序。 同樣，只需顯式啓用後期 RTM 的查詢優化器修補程序。
下表對此行爲進行了彙總：
重要
解決錯誤結果或訪問衝突錯誤的查詢優化器修補程序不受跟蹤標誌 4199 的保護。 這些修補程序並不被視爲可選項。
- 對 SQL Server 和 Azure SQL 數據庫 上發佈的基數估算器的更改僅在 數據庫引擎 新版本的默認兼容性級別中啓用，未在之前的兼容性級別上啓用 。
例如，發佈 SQL Server 2016 (13.x) 時，對基數估算過程的更改僅對使用 SQL Server 2016 (13.x) 默認兼容性級別 (130) 的數據庫可用。 之前的兼容性級別保留了 SQL Server 2016 (13.x) 之前可用的基數估算行爲。
之後，發佈 SQL Server 2017 (14.x) 時，對基數估算過程的新更改僅對使用 SQL Server 2017 (14.x) 默認兼容性級別 (140) 的數據庫可用。 數據庫兼容性級別 130 保留了 SQL Server 2016 (13.x) 基數估算行爲。
下表對此行爲進行了彙總：
| 數據庫引擎版本 | 數據庫兼容性級別 | 新版本 CE 更改 |
|---|---|---|
| 13 (SQL Server 2016 (13.x)) | < 130 | 已禁用 |
| 130 | 已啓用 | |
| 14 (SQL Server 2017 (14.x))1 | < 140 | 已禁用 |
| 140 | 已啓用 | |
| 15 (SQL Server 2019 (15.x))1 | < 150 | 已禁用 |
| 150 | 已啓用 |
1 同樣適用於 Azure SQL 數據庫。
重要
本文的後續部分會介紹特定兼容性級別之間的其他差異。
兼容性級別 140 和兼容性級別 150 之間的差異
此部分介紹了隨兼容性級別 150 一起引入的新行爲。
| 兼容性級別設置爲 140 或更低 | 兼容性級別設置爲 150 |
|---|---|
| 關係數據倉庫和分析工作負荷可能由於 OLTP 開銷、缺少供應商支持或其他限制而無法利用列存儲索引。 如果沒有列存儲索引，這些工作負荷將不能受益於批處理執行模式。 | 批處理執行模式現在適用於分析工作負荷，而無需列存儲索引。 有關詳細信息，請參閱行存儲上的批處理模式。 |
| 請求會導致溢出到磁盤的不充足內存授予大小的行模式查詢可能會繼續對連續執行產生問題。 | 請求會導致溢出到磁盤的不充足內存授予大小的行模式查詢可能會提高連續執行的性能。 有關詳細信息，請參閱行模式內存授予反饋。 |
| 請求會導致併發問題的過多內存授予大小的行模式查詢可能會繼續對連續執行產生問題。 | 請求會導致併發問題的過多內存授予大小的行模式查詢可能會改進連續執行的併發性。 有關詳細信息，請參閱行模式內存授予反饋。 |
| 引用 T-SQL 標量 UDF 的查詢將使用迭代調用、缺乏成本計算並強制串行執行。 | T-SQL 標量 UDF 將轉換爲內聯在調用查詢中的等效關係表達式，這通常會使性能顯著提升。 有關詳細信息，請參閱 T-SQL 標量 UDF 內聯。 |
| 表變量使用固定猜測值來進行基數估計。 如果實際行數遠高於猜測值，則下游操作的性能可能會受到影響。 | 新計劃將使用在首次編譯時遇到的表變量的實際基數，而不是一個固定猜測值。 有關詳細信息，請參閱表變量延遲編譯。 |
有關數據庫兼容性級別 150 中啓用的查詢處理功能的詳細信息，請參閱 SQL Server 2019 中的新增功能和 SQL 數據庫中的智能查詢處理。
兼容性級別 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” |
| 列存儲索引的批處理模式與行模式更改： | 列存儲索引的批處理模式與行模式更改： |
| 1. 具有列存儲索引的表上的排序處於行模式 | 1. 具有列存儲索引的表上的排序現在處於批處理模式 |
| 2. 開窗函數聚合在行模式（如 LAG 或 LEAD）下運行 | 2. 開窗聚合現在在批處理模式（如 LAG 或 LEAD）下運行 |
| 3. 具有多個不同子句的列存儲表的查詢在行模式下運行 | 3. 具有多個不同子句的列存儲表的查詢在批處理模式下運行 |
| 4. 在 MAXDOP 1 下運行或具有串行計劃的查詢在行模式下執行 | 4. 在 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。 |
| 允許使用棄用的 MD2、MD4、MD5、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 數據庫中使用較舊的查詢優化器，必須選擇兼容級別 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 語句可創建並行插入操作。 插入大量行時，並行操作可能會提升性能。 |
低兼容性級別與級別 100 和 110 之間的差異
本節介紹隨兼容性級別 110 引入的新行爲。 此部分還適用於大於 110 的兼容性級別。
| 兼容性級別設置爲 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。 | 兼容級別爲 110 時，對 time 和 datetime2 數據類型的 CAST 和 CONVERT 操作的默認樣式始終爲 121。 如果您的查詢依賴舊行爲，請使用低於 110 的兼容性級別或在受影響的查詢中顯式指定 0 樣式。 將數據庫升級到兼容性級別 110 將不更改已存儲到磁盤的用戶數據。 您必須相應手動更正此數據。 例如，如果使用了 SELECT INTO 來從包含上述計算列表達式的源創建表，將存儲數據（使用樣式 0）而非存儲計算列定義本身。 您需要手動更新此數據，以匹配樣式 121。 |
| 在分區視圖中引用的遠程表的所有 smalldatetime 類型的列都將映射爲 datetime。 本地表中相應的列（在選擇列表中的相同序號位置中）必須爲 datetime 類型。 | 在分區視圖中引用的遠程表的所有 smalldatetime 類型的列都將映射爲 smalldatetime。 本地表中相應的列（在選擇列表中的相同序號位置中）必須爲 smalldatetime 類型。 |
| 在升級到 110 後，分佈式分區視圖將由於數據類型不匹配而失敗。 可以通過將針對遠程表的數據類型更改爲 datetime 或者將本地數據庫的兼容級別設置爲 100 或更低，解決上述問題。 | |
| SOUNDEX 函數實現以下規則： | SOUNDEX 函數實現以下規則： |
| 1) 當分隔兩個具有相同 SOUNDEX 代碼的輔音時，將忽略大寫 H 或大寫 W。 | 1) 如果大寫 H 或大寫 W 分隔具有相同 SOUNDEX 代碼的兩個輔音，則將忽略右側的輔音 |
| 2) 如果 character_expression 的前 2 個字符具有相同的 SOUNDEX 代碼，則將包含這兩個字符。 否則，如果一組並行輔音在 SOUNDEX 代碼中有相同的數字，所有這些輔音都會被排除在外，第一個輔音除外。 SOUNDEX 函數實現以下規則： | 2) 如果一組並行輔音在 SOUNDEX 代碼中有相同的數字，所有這些輔音都會被排除在外，第一個輔音除外。 |
| 其他規則可能導致由 SOUNDEX 函數計算的值不同於在更低數據庫兼容級別時計算的值。 在升級到兼容級別 110 後，可能需要重新生成使用 SOUNDEX 函數的索引、堆或 CHECK 約束。 有關詳細信息，請參閱 SOUNDEX。 |
兼容性級別 90 和兼容性級別 100 之間的差異
略！
保留關鍵字
兼容性設置還確定了數據庫引擎所保留的關鍵字。 下表顯示了每個兼容性級別所引入的保留關鍵字。
| 兼容性級別設置 | 保留關鍵字 |
|---|---|
| 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” 。
有關詳細信息，請參閱保留關鍵字。
權限
需要對數據庫擁有 ALTER 權限。
示例
A. 更改兼容性級別
以下示例將 AdventureWorks2012 數據庫的兼容性級別更改爲 SQL Server 2012 (11.x) 的默認值 110。
ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO
以下示例返回當前數據庫的兼容級別。
SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();
B. 忽略 SET LANGUAGE 語句（除非低於兼容級別 120）
只有兼容級別低於 120 時，以下查詢纔會忽略 SET LANGUAGE 語句。
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 子句右側的遞歸引用產生無限循環
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。
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 運算符
在包含頂級 UNION 運算符的語句中，允許使用變量賦值，但會返回意外的結果。 例如，在以下語句中，將來自兩個表的聯合的 @v 列的值賦給局部變量 BusinessEntityID。 按照定義，如果 SELECT 語句返回多個值，則將返回的最後一個值賦給變量。 在這種情況下，會正確地將最後一個值賦給變量，但還會返回 SELECT UNION 語句的結果集。
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;
在包含頂級 UNION 運算符的語句中不允許變量賦值。 返回錯誤 10734。 若要糾正該錯誤，請重寫查詢，如下例所示。
DECLARE @v int;
SELECT @v = BusinessEntityID FROM
(SELECT BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;