跨數據庫的索引使用情況
我想諮詢在以下情況下獲得性能的最佳方法是什麼。這是在 SQL2016 伺服器上。
我有一個新創建的中央數據庫，其中數據從另一個系統複製到。由於遺留原因，我在同一台伺服器上有部門特定的數據庫，其中包含對中央數據庫數據的部門拆分視圖。複製曾經直接進入那些。
所以新的結構是：
CentralDB 擁有 Table1、Table2、Table3。
Dept1DB 擁有 Table1 的視圖，其中包含 WHERE 子句以按 Dept1 進行過濾。
Dept2DB 持有 Table1 的視圖，其中包含 WHERE 子句以按 Dept2 進行過濾。
Dept3DB 擁有 Table1 的視圖，其中包含 WHERE 子句以按 Dept3 進行過濾。
等用於舊版本中的每個部門和每個表。
有些視圖很簡單，但有些視圖更複雜，因為用於過濾的部門列不直接在表中。所以一些 INNER JOIN 是有序的。
現在，問題是從這種情況中獲得一些性能的最佳方法是什麼。有些查詢可能很繁重，雖然大多數表只有幾萬行，但其他查詢可能有數百萬行。CentralDB 將在 500Go 左右給出觀點。除了密切監視 CentralDB 上的索引之外，還有更好的解決方案嗎？我正在尋找更多深入探索的途徑和可能性。
（遺留原因：有大量內部遺留應用程序直接使用 DeptDB，我們現在不希望重寫以直接指向新的 CentralDB，因此我們需要這種“欺騙”來通過訪問視圖來欺騙他們。）
非常感謝。
我試著回答你所有的問題：
- 如果我在 CentralDB 的表上創建索引，視圖會使用它嗎？
可以肯定的是，如果視圖中使用了索引列，例如您的範例中的部門程式碼。
- 列儲存索引是更好的選擇嗎？
是和否，這取決於行數和中央表的使用情況。這是你必須測試的東西。
- 創建索引視圖會更好嗎？
不，因為您不能索引引用外部表的視圖。
- 是否有其他方法可以確保跨數據庫的東西正常工作？
跨數據庫查詢本身執行良好，就像查詢不跨數據庫一樣。您的方式很好，但一般來說最好的是重新設計應用程序，尤其是舊應用程序。如果您不想這樣做，則必須以性能問題的形式支付。始終依賴關係理論和範式。