將索引視圖上的計算欄位添加到 SQL Server 中的表後，如何測量 I/O 爭用？

我已經成功地將幾個計算欄位添加到不同的表中，例如：

ALTER TABLE dbo.tblBGiftVoucherItem
ADD isUsGift AS CAST(
   (
       ISNULL(
       CASE 
           WHEN sintMarketID = 2 
               AND strType = 'CARD' 
               AND strTier1 LIKE 'GG%' THEN 1 
           ELSE 0 
       END
       ,0)
   ) AS BIT)
PERSISTED;

在這種情況下，這似乎對相關表的寫入性能沒有任何影響dbo.tblBGiftVoucherItem。

但是，當我添加索引視圖時，尤其是那些接觸多個帶有 的表時INNER JOIN，我注意到與相關表直接相關的死鎖數量顯著增加。

我可以使用哪些 DMV 來指示數據庫對象的 I/O 壓力？

例如上面範例中的表格dbo.tblBGiftVoucherItem。

有什麼方法可以測量/監控儲存引擎處理與該表特別相關的寫入請求需要多長時間？

如果我知道這一點，我會更好地了解我可以添加到表中的計算欄位數量，以及每個欄位所涉及的成本。

與索引視圖相同。

我可以使用哪些 DMV 來指示數據庫對象的 I/O 壓力？

可能最接近的是sys.dm_db_index_operational_stats。這為數據庫中表或索引的每個分區提供了低級 I/O、鎖定、鎖存和訪問方法活動。

添加持久化計算列通常影響不大，但如果被索引，它們會增加通常的額外成本。這只是添加索引的正常權衡，而不是特定於正在計算的基礎列。

使用索引視圖往往會增加死鎖的機會，因為索引視圖維護必須在內部以可序列化的隔離級別（通常獲取事務長度鍵範圍鎖）執行，以保證在引用多個表時的一致性。看法。

相關問題：事務隔離級別的隱式更改是如何、何時以及為什麼發生的？

如果視圖包含聚合，索引視圖也會增加不兼容鎖的風險，因為這具有將基礎表中的數據范圍集中到索引視圖中較少行的效果。

添加索引和索引視圖時總是需要權衡取捨。在許多情況下，死鎖風險可以通過仔細設計和關注為修改附加索引的語句生成的執行計劃的細節而最小化。

我的另一條建議是考慮投資商業績效監控工具。可以基於 DMV 編寫自己的程式碼，但這並不總是那麼容易，並且在這些產品中已經完成了很多艱苦的工作（包括展示和歷史報告）。

引用自：https://dba.stackexchange.com/questions/116881