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、110、100 |
| SQL Server 2017 (14.x) | 14 | 140 | 140、130、120、110、100 |
| Azure SQL Database 邏輯服務器 | 12 | 130 | 150、140、130、120、110、100 |
| Azure SQL Database 托管實例 | 12 | 130 | 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 | 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。
執行以下查詢可確定連接到的 數據庫引擎的版本。
SELECT SERVERPROPERTY('ProductVersion'); 備注
Azure SQL Database上並不支持所有功能（因兼容級別而異）。
若要確定當前兼容級別，請查詢 sys.databases (Transact-SQL) 的 compatibility_level 列。
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" |
列存儲索引的批處理模式與行模式更改：
|
列存儲索引的批處理模式與行模式更改：
|
| 可以自動更新統計信息。 | 自動更新統計信息的邏輯對大型表更主動。 在實踐中，這應減少以下情況：對於經常查詢新插入的行，但是未更新統計信息以包括這些值的查詢，客戶遇到性能問題。 |
| 在 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 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)。
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 (Transact 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 語句的結果集。
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。 若要糾正該錯誤，請重寫查詢，如下例所示。
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)
查看或更改數據庫的兼容級別