CLR集成性能設計選擇的示例分析

這篇文章將為大家詳細講解有關CLR集成性能設計選擇的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

1.編譯過程

在編譯 SQL 表達式時，如果遇到對托管例程的引用，則生成 Microsoft 中間語言 (MSIL) 存根。該存根包含的代碼用于將例程參數從 SQL Server 封送到 CLR、調用函數并返回結果。該“粘附”代碼基于參數類型和參數方向（向內、向外或引用）。粘附代碼支持特定于類型的優化，并確保有效地強制實現 SQL Server 語義，例如為 Null 性、約束方面、按值和標準異常處理。通過為確切類型的參數生成代碼，可以避免跨調用邊界的類型強制或包裝對象創建開銷（稱為“裝箱”）。隨后，使用 CLR 的 JIT（實時）編譯服務將生成的存根編譯為本機代碼，并針對 SQL Server 執行所在的特定硬件體系結構進行優化。JIT 服務是在方法級別調用的，并允許 SQL Server 宿主環境創建一個跨 SQL Server 和 CLR 執行的編譯單元。編譯存根之后，生成的函數指針即成為函數的運行時實現。此代碼生成方法確保不會發生與運行時反射或元數據訪問相關的其他調用開銷。

在 SQL Server 和 CLR 之間快速轉換
編譯過程生成的函數指針可以在運行時通過本機代碼調用。對于標量值用戶定義函數，可基于每行調用此函數。為***程度地降低在 SQL Server 和 CLR 之間轉換的成本，包含任何托管調用的語句都具有一個標識目標應用程序域的啟動步驟。該標識步驟減少每行的轉換成本。

2.性能注意事項
 
以下內容概述了 SQL Server 中特定于CLR集成性能的注意事項。有關更多詳細信息，請參閱 MSDN 網站上的“Using CLR Integration in SQL Server 2005”（在 SQL Server 2005 中使用 CLR 集成）。有關托管代碼性能的常規信息，請參閱 MSDN 網站上的“Improving .NET Application Performance and Scalability”（提高 .NET 應用程序的性能和可擴展性）。

3.用戶定義函數

相較于 Transact-SQL 用戶定義函數，CLR 函數可以從更快的調用路徑中受益。此外，同 Transact-SQL 相比，托管代碼在過程代碼、計算和字符串操作方面具有決定性性能優勢。需要大量計算和不執行數據訪問的 CLR 函數采用托管代碼編寫時效果更好。但是與CLR集成性能相比，Transact-SQL 函數的確可以更有效地執行數據訪問。

4.用戶定義聚合

托管代碼的性能大大優于基于游標的聚合。托管代碼的執行速度通常稍慢于內置 SQL Server 聚合函數的執行速度。如果存在本機內置聚合函數，建議您使用該函數。對于所需聚合不受本機支持的情況，出于性能原因，請考慮使用 CLR 用戶定義聚合，而不是基于游標的實現。

5.流式表值函數

應用程序通常需要返回一個表作為調用函數的結果。示例包括從文件讀取表格格式數據作為導入操作的一部分，并將逗號分隔值轉換為關系表示形式。通常，您可以通過在調用方使用結果表之前具體化和填充此結果表來實現此目的。CLR 與 SQL Server 的集成引入了一種名為流式表值函數 (STVF) 的新擴展性機制。托管 STVF 的性能優于可比擴展存儲過程實現的性能。STVF 是返回 IEnumerable 接口的托管函數。IEnumerable 具有導航 STVF 返回的結果集的方法。當調用 STVF 時，返回的 IEnumerable 直接連接到查詢計劃。查詢計劃在需要提取行時調用 IEnumerable 方法。使用此迭代模型，結果在***行生成之后即可使用，而不需要等到整個表填充完。還可以極大地減少調用該函數而占用的內存。

6.數組與游標

當 Transact-SQL 游標必須遍歷更容易表示為數組的數據時，使用托管代碼可以顯著提高性能。

7.字符串數據

SQL Server 字符數據（如 varchar）在托管函數中可以是 SqlString 或 SqlChars 類型。SqlString 變量將整個值的實例創建到內存中。SqlChars 變量提供可用于獲得更好性能和可擴展性的流式接口，而無需將整個值的實例創建到內存中。這對于大型對象 (LOB) 數據尤為重要。此外，還可以通過 SqlXml.CreateReader() 返回的流式接口訪問服務器 XML 數據。

8.CLR 與擴展存儲過程

允許托管過程向客戶端回發結果集的 Microsoft.SqlServer.Server 應用程序編程接口 (API) 的性能優于擴展存儲過程使用的開放式數據服務 (ODS) API。此外，System.Data.SqlServer API 支持 xml、varchar(max)、nvarchar(max) 和 varbinary(max) 等 SQL Server 2005 中引入的數據類型，但是尚未將 ODS API 擴展為支持新的數據類型。

通過托管代碼，SQL Server 管理對內存、線程和同步等資源的使用。這是因為公開這些資源的托管 API 是針對 SQL Server 資源管理器實現的。相反，SQL Server 無法查看或控制擴展存儲過程的資源使用情況。例如，如果擴展存儲過程占用過多 CPU 或內存資源，則無法通過 SQL Server 檢測或控制此種情況。但是，SQL Server 可以使用托管代碼檢測到給定線程已有很長一段時間未生成結果，并強制該任務生成以便安排其他工作。因此，使用托管代碼可以提高可擴展性，并改善系統資源使用情況。托管代碼可能帶來維護執行環境和執行安全檢查所需的額外開銷。例如，當在 SQL Server 內運行并需要執行從托管代碼到本機代碼的大量轉換時，可能會發生此種情況（因為在托管代碼和本機代碼之間來回轉換時，SQL Server 需要對特定于線程的設置進行額外維護）。因此，對于在托管代碼和本機代碼之間進行頻繁轉換的情況，擴展存儲過程的性能大大優于在 SQL Server 內運行的托管代碼的性能。

注意：
建議您不要開發新的擴展存儲過程，因為已不推薦使用此功能。

9.用戶定義類型的本機序列化

用戶定義類型 (UDT) 是作為標量類型系統的擴展性機制設計的。SQL Server 實現稱為 Format.Native 的 UDT 序列化格式。在編譯期間，檢查該類型的結構以便生成針對該特定類型定義自定義的 MSIL。本機序列化是針對 SQL Server 的默認實現。用戶定義序列化調用由類型作者定義的方法以執行序列化。應盡可能使用 Format.Native 序列化以便獲取***性能。

10.可比 UDT 的規范化

關系操作（例如對 UDT 進行排序和比較）是針對值的二進制表示形式直接執行的。通過在磁盤上存儲 UDT 狀態的規范化（二進制排序）表示形式可以實現此目的。規范化具有兩個優點：避免構造類型實例和方法調用開銷，進而極大地降低了比較操作的成本；為 UDT 創建二進制域，支持構造直方圖、索引以及該類型的值的直方圖。因此，規范化 UDT 的性能配置文件類似于未涉及方法調用的操作的本機內置類型性能配置文件。

11.可擴展內存使用量

為了在 SQL Server 中很好地執行和調整托管垃圾回收，請避免使用大型單一分配。大小大于 88 千字節 (KB) 的分配將被放置到大對象堆，這將導致垃圾回收的性能和調整結果遠不如多個較小分配的性能和調整結果。例如，如果需要分配一個大型多維數組，***分配一個交錯（分散）數組。

關于“CLR集成性能設計選擇的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。