原帖地址：https://www.cnblogs.com/jinanxiaolaohu/p/10030021.html ALTER DATABASE (Transact-SQL) 相容級別 https://docs.microsoft.com/zh-cn/sql/t-sql/statements/a ...
原帖地址：https://www.cnblogs.com/jinanxiaolaohu/p/10030021.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、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。
執行以下查詢可確定連接到的 資料庫引擎的版本。
SQLSELECT SERVERPROPERTY('ProductVersion');
備註
Azure SQL Database上並不支持所有功能（因相容級別而異）。
若要確定當前相容級別，請查詢 sys.databases (Transact-SQL) 的 compatibility_level 列。
SQLSELECT 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”。 |
  更多相關文章
一周排行
 所有分類
|