所以我有一個總結，我需要返回到最終用戶應用程序。服務器之間的SQL臨時表加入
它應該接受3個參數DateType，StartDate，EndDate。
日期類型將確定我用於過濾數據的日期字段。
我完成這項工作的方法是將所有記錄的ID記錄到TEMP表中，然後將我的摘要加入到ID列表中。
在存儲數據的SQL服務器上的查詢上運行時，此工作正常。
但是，這是一個複製的服務器，所以當我編譯到一個存儲過程，並與應用程序數據的其餘部分在服務器上時，它會減慢查詢速度。 IE 2秒對50秒。
我認爲從SQL服務器上創建的臨時表開始加入到replciation服務器上的表的交叉連接正在導致速度減慢。
是否有任何方法或技術可用於解決此問題並在一個存儲過程中構建這一切？
如果我用他們自己的日期範圍創建3個存儲過程，那麼他們又快了。但是，這意味着要維護多個存儲過程以實現同一事物。
首先，如果您運行的是早於2012 SP1的SQL Server版本，則一個問題是不允許用戶運行DBCC SHOW_STATISTICS（這是大多數不是系統管理員的用戶，請參閱「權限」文檔中的部分）不能訪問遠程表上的統計信息。這可能會嚴重削弱優化程序生成良好執行計劃的能力。升級SQL Server或授予更多權限可以在此幫助。
如果您的查詢涉及過濾或加入字符列，請確保遠程服務器在鏈接服務器選項中標記爲「整理兼容」。如果此選項關閉，則SQL Server不能假定跨服務器的字符串可以進行比較，並且它將開始向上和向下抽取整個表格，以確保數據在比較必須完成的地方結束。
如果執行計劃一樣好，但仍然不夠好，一種通用（不合格）技術是首先在本地傳輸所有數據（SELECT * INTO #localtable FROM remote.db.schema.table），然後將查詢作爲非分佈式查詢運行。很明顯，爲了這個工作起來，遠程表不能太「太大」，並且在某些情況下，這實際上性能更差，這取決於涉及多少行。但是總是值得考慮，因爲優化器在本地表上做得更好。
另一種避免跨服務器將表拉到一起的方法是將參數中的數據打包到遠程存儲過程調用中。整個表格可以通過XML通過NVARCHAR(MAX)傳遞，因爲在分佈式查詢中既不支持XML列，也不支持表值參數。基本思想是一樣的：避免優化器找出有效的分佈式查詢的需要。顯然，最好的方法很大程度上取決於你的數據和你的查詢。