爲緩存記錄創建視圖或新表

我在一個傳統應用程序中遇到巨大的性能問題。爲緩存記錄創建視圖或新表

有一個搜索表單，用戶可以搜索給定值的記錄。結果行包含10列。然後SP返回任何列中包含該值的行。

該SP使用8個表格，其中一些具有約百萬條記錄。每一分鐘我都會有新的記錄。該SP也進行分頁。執行此SP有時需要大約40秒。

我所做的是，我創建了一個新表，並通過使用來自此SP的查詢來放置所有記錄，但沒有條件。當在源表中有一個新的更新或更新時，我使用觸發器並更新這個新的「緩存」表。現在等待這個新表格的結果只需要1-3秒。

有沒有人喜歡這樣的經驗？

其中一位同事說我最好使用視圖，但後來每次我都會製作JOINS。

您認爲如何？有另一種方法嗎？

來源

2015-05-24 user278618

如果您展示了一些示例表和代碼，這將會很有幫助。只是從描述中理解你的情況有點困難。 –

對不起，我真的不能。問題在於，如果將所有這些表格中的部分信息合併爲一張表格，這是最佳解決方案。如果我很好地理解這個概念，它與NoSql類似。 – user278618

我建議你在複製任何數據之前檢查相關表的索引。 –

您可以使用模式綁定視圖並在view上創建聚簇索引。它將以物理方式存儲您的視圖數據。但創建模式綁定視圖後，您無法更改表格。

來源

2015-05-25 07:27:45

臨時表通常可以幫助您解決性能問題。一種方法可能是僅收集需要考慮到臨時表中的記錄，然後從臨時表中創建最終的選擇語句，並將其添加到任何其他未過濾的表中。

舉一個例子，假設您正在搜索的字段之一是field1 in table1。通過插入到表#table1只有具有的field1值記錄你正在尋找開始：

select PrimaryKeyTable1, Field1, Field2, Field3, etc... 
into #table1 
from table1 
where Field1 = 'Whatever you are looking for'

這應該是非常快，即使是大表，特別是如果你有Field1的索引。您可以爲每個帶有搜索字段的表執行此操作，以收集您正在搜索的具有相關記錄的所有記錄。

然後，您還需要確保將任何記錄插入到您的臨時表中，這些記錄可能具有對任何其他臨時表的外鍵引用。假設您還使用上述方法構建了表#table2，該方法具有一個名爲PrimaryKeyTable1的table1的外鍵。你會像插入這些記錄：

Insert into #table1 
    (PrimaryKeyTable1, Field1, Field2, Field3, etc...) 
select table1.PrimaryKeyTable1, table1.Field1, table1.Field2, table1.Field3, etc... 
from table1 
join #table2 
on table1.PrimaryKeyTable1 = table2.PrimaryKeyTable1 
where table1.PrimaryKeyTable1 not in 
    (Select PrimaryKeyTable1 from #table1)

現在，您也將有#table1匹配，達到創紀錄的#table2包含符合搜索條件的記錄中的任何記錄。您可以爲所有具有相關外鍵的臨時表執行此操作。你插入的順序很重要;請確保在收集外鍵引用記錄時，不要在最後一條插入語句之後引用任何臨時表。

然後，您可以簡單地執行最終選擇語句，用您已構建的臨時表替換實際表格，並刪除搜索字段數據的所有過濾器。根據查詢的結構可能會有其他優化，但這是一般的想法。

如果您已經探索了所有的索引選項，但這仍然無濟於事，MS SQL Server具有「更改跟蹤」功能，可能在構建緩存表時使用它。您啓用數據庫進行更改跟蹤並配置您希望跟蹤的表。 SQL Server然後在每次更新時創建更改記錄，在表上插入和刪除，然後讓您查詢自上次檢查以來所做的記錄更改。這對於同步更改非常有用，並且比使用觸發器更有效。這比管理自己的跟蹤表更容易管理。這是一個功能，因爲SQL Server 2005的

How to: Use SQL Server Change Tracking

變化只跟蹤捕獲表的主鍵和讓您查詢哪些領域可能已被修改。然後，您可以查詢這些鍵上的表連接以獲取當前數據。如果你想要捕獲數據，你也可以使用Change Capture，但是它需要更多的開銷，並且至少需要SQL Server 2008企業版。

Change Data Capture

來源

2015-05-26 22:04:54

謝謝Brian的回答。但是這個SP已經以這種方式使用了臨時表。 – user278618

沒問題。我添加了另一個選項來幫助您將緩存表構建到我的答案中。 –

，看起來很有希望。謝謝@Brain – user278618

你的解決方案是在做所謂的Microsoft SQL Server「索引視圖」或甲骨文「物化視圖」的一個可靠的方法。

基本上你是正確的 - 導航單個索引表然後是不斷更新的十幾個表更快。

你應該真的嘗試創建一個索引視圖（一些從這裏開始https://technet.microsoft.com/en-us/library/dd171921(v=sql.100).aspx），它可能會解決你所有的性能問題。

來源