更改 SQL Server 2008 R2 數據庫後性能不佳
需要一些關於我可以做些什麼來追踪這個問題的提示。我的客戶有一個中等大小的 SQL Server 2008 R2 數據庫（大約 6 gigs 大小）。
上週我修改了數據庫，為大約 6 個（一百個）表添加了一個新欄位，並對使用這些表的視圖和儲存過程進行了相應的更改 - 全部完成，非常小的更改。
問題是，對於一個我沒有修改的儲存過程，性能變得非常糟糕。過去需要 8 秒執行，現在至少需要 10 分鐘，而且由於該報告是全天執行的，因此當有人執行它時，它往往會扼殺其他人的表現。
我已經使用 Red Gate 的 SQL 比較來嘗試找出發生了什麼變化，除了我添加的新欄位，但找不到任何可以解釋差異的東西 - 所以問題是，我該如何調試呢？我在同一台機器上有一個 6 個月大的數據庫副本，我仍然可以在 8 秒內執行這個 SP；SP 是一樣的，索引似乎都一樣，我更新了統計資訊，重新編譯了視圖並重新編譯了所有儲存過程，但似乎仍然無法恢復性能。
所以對於你更有經驗的 DBA 的問題，我該如何解決這個問題？我查看了執行計劃，但坦率地說，SP 非常複雜，步驟太多，難以閱讀——而且我不知道我在尋找什麼。
建議？
編輯：為了澄清，我沒有升級硬體或 SQL Server 的版本，只是一些底層表的變化；6 個月大的數據庫副本仍然執行得非常快，只比目前版本小 10% 左右，因此雖然有增長，但沒有什麼可以解釋 60 倍的性能下降。
慢速計劃連結： https ://www.dropbox.com/s/arg2s5psav3slj3/SlowPlan.sqlplan
快速計劃連結： https ://www.dropbox.com/s/2frmzqqajtpy9q2/GoodPlan.sqlplan
所以我第一眼看到的主要區別是表掃描在
ARMiscIncome慢版本中提供了一個合併連接，這需要一個排序：
但在快速版本中，它提供雜湊連接（因此不需要排序）：
這種排序是慢速計劃中最高的總體成本，所以我可能建議要麼在那裡進行雜湊連接（這可能只是由於兩個系統中的行數不同，即使統計數據已過時），或者添加一個索引，例如滿足輸出的這個：
CREATE INDEX SortHelper ON dbo.ARMiscIncome(GuestID) INCLUDE (Amount, ChargeCode, DateEntered, Description, TranDate);（或更改該表上的聚集索引。）
通常需要注意，例如添加/更改索引可能有助於此特定查詢，但可能對其他人沒有幫助，和/或可能會對 DML 操作造成過度壓力。但當然值得徹底測試恕我直言。
順便說一句，通過比較SentryOne Plan Explorer中的計劃，我能夠找到最昂貴的運營商。這是一個免費工具，它使這種類型的調查比在 Management Studio 中更輕鬆。
在您的慢速計劃中，您有大量在快速計劃中遺漏的堆 RID 查找。看起來好像您的聚集索引消失了，或者您現在缺少一些以前擁有的覆蓋索引，尤其是在
ARChargeand上ARPayAdj。