SQL Server鏈接服務器性能

Question

我正在使用SQL Server 2008 Enterprise。 我正在使用鏈接服務器技術從另一台服務器鏈接另一個SQL Server 2008 Enterprise實例。 我編寫TSQL來處理來自兩個服務器實例的對象（例如表）。

我的問題是，對於鏈接服務器，是否存在很大的性能問題？ 如果是，我們應遵循的關鍵性能瓶頸和最佳實踐是什么？

喬治，提前謝謝

Answer 1

我的問題是，對於鏈接服務器，是否存在很大的性能問題？ 如果是，我們應遵循的關鍵性能瓶頸和最佳實踐是什么？

相比什么？ 有什么疑問？ 當然這一切都取決於你在做什么。 對於某些查詢，對於其他大量的搜索，性能損失可以忽略不計。

你應該記住一些問題：

• 如果你將從DB1加入2個表到DB2的2個表，並且表很大，那么東西就會變得很難看。 在一天結束時，查詢將在某處執行。 db必須將所有結果提取到主數據庫並在主數據庫上維護事務完整性。 這可能非常昂貴。
• 如果你開始運行分布式事務，那么事情會變得很丑陋 ，快速。
• 當跨服務器連接東西時，遠程服務器上的索引可能變得無用。 所有數據都必須移動到某個連接處。
• 鏈接的服務器鏈接可能會在意外時間發生故障並導致難以診斷錯誤。

在過去，我發現在本地移動遠程數據的速度要快幾個數量級，並在加入之前對其進行索引。

Answer 2

這取決於你在做什么。

如果您正在運行在兩個服務器實例中的表之間連接的查詢，並傳輸大量數據，那么您有一個需要注意的瓶頸。

如果服務器位於擁有1GB鏈接的自己的子網上，那么您不必擔心太多問題。 如果兩個服務器通過共享的慢速鏈接連接，我會擔心。

Answer 3

你需要點擊一下才能將結果傳輸兩次（將服務器連接到SQL Server到你的機器）。 其次，它必須解析名稱並登錄，這不是很重要，但它仍然是一個打擊。

無論如何，我發現唯一的主要瓶頸是跳躍服務器，因為它必須傳輸兩次信息。

Answer 4

我經常使用鏈接服務器在環境之間同步數據，主要是因為我發現它是最簡單的代碼和管理解決方案。

我找到的一個提示，但可能不是其他人的選擇，是在服務器上運行具有最多數據或正在進行最多更新/插入的任何過程。 例如，我有一個過程比較兩個表和插入/更新從A到B.如果我在服務器A上運行它，它將比在B上運行過程花費很多倍。如果你沒有選擇在哪里運行我們的代碼，你被卡在服務器A上，然后這個建議可能沒有幫助。

另一個提示是將返回的數據減少到必要的最小值。 雖然您通常可以在本地服務器上立即返回數據，但如果鏈接服務器距離較遠，那么延遲可能會非常痛苦。 在訪問您需要的列時要比正常更嚴格。

Answer 5

我發現如果你正在進行外連接（左/右），性能會快速下降。 有時候從遠程服務器中選擇數據到臨時表並對其進行索引而不是通過網絡加入有時會更快。 大多數情況下，最好的策略是以有意義的方式編寫查詢，然后只在性能成為真正問題時才調整查詢。

Answer 6

@ George2，

Sam Saffron在這種情況下是正確的。 在本地執行連接時，SQL Server使用索引執行連接，然后查找未包含在索引定義中的列。

使用鏈接服務器進行連接，首先需要從遠程服務器傳輸所有表，然后執行連接。 這是一個瓶頸。 如果您可以在將所有遠程表連接到本地表之前對其進行預過濾，那么它將顯着提高性能（例如，選擇具有良好過濾器的#temp表以減少行數），然后如果您需要對該表執行多個操作，那么最好立即創建一個索引。