? 前言： 本文是對博客 http://www.dbnewsfeed.com/2012/09/08/5-performance-killers-when-working-with-linked-servers/ 的翻譯 , 如有翻譯不對或不好的地方，敬請指出，大家一起學習進步。尊重原創(chuàng)和翻譯勞動成果，轉載時請注明出處。謝謝！
?
當使用鏈接服務器（Linked Servers）時，最昂貴的代價就是網(wǎng)絡帶寬間大量數(shù)據(jù)的傳輸。在正確的服務器書寫正確的代碼是非常重要的，因為每一個錯誤都會導致在網(wǎng)絡帶寬上付出非常昂貴的代價。 下面是使用鏈接服務器（Linked Servers）時的幾個常見錯誤：
1：使用推送方式而不是拉方式取數(shù)
?? 出人意料之外的是，使用鏈接服務器推送數(shù)據(jù)比拉取數(shù)據(jù)慢得多。Linchi Shea寫了一篇很好的 博客 討論這個。
?? Linchi Shea 使用openquery來說明兩者間的差異，但是這個也會發(fā)生在使用鏈接服務器的SQL語句中（這里不好翻譯，其實就是查詢中使用Linked Server需要用到 LinkServer.DatabaseName.dbo.TableName）
2： 使用JOIN
??? 跨服務器查詢時，為了在兩臺服務器之間的數(shù)據(jù)集之間執(zhí)行JOIN操作，SQL Server需要將數(shù)據(jù)從一臺服務器傳送到另外一臺服務器。如果傳送的數(shù)據(jù)是一個非常大的表，這個過程可能會非常痛苦。通常來說，數(shù)據(jù)會從遠程服務器傳送到本地服務器。為了防止大量數(shù)據(jù)在服務器之間大傳送，你可以通過在查詢條件中過濾數(shù)據(jù)，通過一個遠程存儲過程只取回相關數(shù)據(jù)來達到目的，萬一你需要使用INNER JOIN關聯(lián)兩個不同服務器之間的數(shù)據(jù)集，而且本地表的數(shù)據(jù)量遠小于遠程服務器的那個表。你可以使用REMOTE JOIN HINT， 這樣就會將數(shù)據(jù)從本地服務器將數(shù)據(jù)傳送到遠程服務器，從而提高性能
3：使用UNION
??? 正如JOIN操作，UNIION不同服務器之間的兩個數(shù)據(jù)集必定導致從遠程服務器傳送數(shù)據(jù)到本地服務器。即使你執(zhí)行遠程查詢合并（UNION）同一個遠程服務器的兩個數(shù)據(jù)集，還是會先將兩個數(shù)據(jù)集傳送到本地服務器，然后UNION兩個數(shù)據(jù)集，可以通過遠程存儲過程，函數(shù)或視圖先UNION數(shù)據(jù)庫來阻止這個
4：書寫太復雜的查詢語句
? 優(yōu)化器不能總是能明白你需要做什么，尤其是你的SQL語句中使用了鏈接服務器（Linked Server）時，例如， 我遇到過一個類似如下SQL語句，執(zhí)行了10分鐘
1:
SELECT
*
2:
FROM
LocalTable
3:
WHERE
SomeColumn <
4:
(
SELECT
COUNT
(*)
5:
FROM
RemoteServer.SomeDB.dbo.SomeTable
6:
WHERE
SomeColumn > 100)
我像這樣修改了查詢語句
1:
DECLARE
@
Count
INT
2:
SELECT
@
Count
=
COUNT
(*)
3:
FROM
RemoteServer.SomeDB.dbo.SomeTable
4:
WHERE
SomeColumn > 100
5:
6:
SELECT
*
7:
FROM
LocalTable
8:
WHERE
SomeColumn < @Count
這樣重寫SQL后，查詢語句只跑了一秒就查詢出結果了，保持SQL腳本簡單。
5：當數(shù)據(jù)庫位于同一個實例時使用鏈接服務器（Linked Server）
??
這種場景的性能損耗可能不像其它場景那樣明顯，但是這種方式比使用數(shù)據(jù)庫前綴（Database.dbo.TableName)要慢
如果你想?yún)^(qū)別這兩種情形，可以在測試數(shù)據(jù)庫測試、對比這兩種方法的性能，然后決定性能的提升是否值得在生產(chǎn)環(huán)境修改代碼。在某些情況下，它是會提升性能的。
?
---------------------------------------
自己的體會、理解
----------------------------------------------
??? 關于SQL SERVER的鏈接服務器（Linked Servers）這項功能，跨數(shù)據(jù)庫/跨服務器查詢時非常有用(比如分布式數(shù)據(jù)庫系統(tǒng)中)，開發(fā)人員尤其喜歡使用它連接到遠程數(shù)據(jù)源查詢數(shù)據(jù)，甚至都到了濫用的地步。正所謂很多東西都具有兩面性，鏈接服務器(Linked Servers)給跨服務器查詢、分布式查詢帶來方便、簡單化的同時，也帶來了性能、安全等一系列問題。
1：性能問題
??? 在復雜環(huán)境下（大數(shù)據(jù)時代更是如此），可能需要在多個不同服務器之間的數(shù)據(jù)庫進行數(shù)據(jù)交互。由于數(shù)據(jù)可以無處不在，開發(fā)人員自然要編寫一個查詢聯(lián)接盡可能多的數(shù)據(jù)可以不考慮它是本地的還是遠程的。于是鏈接服務器的大量使用應運而生，但是鏈接服務器的濫用和不合理使用可能會導致數(shù)據(jù)庫出現(xiàn)很多ASYNC_NETWORK_IO等待事件。另外，書寫不好的SQL有可能導致嚴重的性能問題。
? 解決方法：你可以通過發(fā)布-訂閱或者作業(yè)將數(shù)據(jù)集（表）數(shù)據(jù)先同步到本地服務器，然后將SQL腳本中的鏈接服務器去掉，這樣對SQL查詢性能有非常大的提升，尤其是查詢比較頻繁或數(shù)據(jù)量大的SQL語句。但是這樣隨之而來了其它問題： 同步數(shù)據(jù)的及時性（作業(yè)同步數(shù)據(jù)）、額外的精力去管理、監(jiān)控數(shù)據(jù)同步（發(fā)布-訂閱）。
? SQL里面使用了Linked Servers導致性能低下，一方面是由于網(wǎng)絡數(shù)據(jù)傳送的延時，另外一方面則是優(yōu)化器不能很好的生成最佳的執(zhí)行計劃. 解釋:由于權限問題，使用了鏈接服務器（Linked Servers）的SQL導致SQL SERVER優(yōu)化器不能利用遠程服務器這些表的統(tǒng)計信息，從而不能生成最優(yōu)的執(zhí)行計劃。如果SQL SERVER優(yōu)化器可以利用到遠程服務器相關表的統(tǒng)計信息，則鏈接服務器使用的賬號必須擁有sysadmin、 db_owner, db_ddladmin這樣的角色，但是很多時候處于安全考慮，創(chuàng)建鏈接服務器時使用的賬號往往沒有這么大的權限。在SQL SERVER 2012 SP1中這個問題已經(jīng)解決了，只需要擁有SELECT權限就可以使用遠程服務器相關表的統(tǒng)計信息。
?
下面這段摘自
TOP 3 PERFORMANCE KILLERS FOR LINKED SERVER QUERIES
----------------------------------------------------------------------------------------------------------------
1. INSUFFICIENT PERMISSIONS
Without a doubt this is the number one reason for why linked server query performance suffers. Historically in order for SQL Server to take advantage of using statistics on the remote server then the login used to make the connection on the remote servers needed sufficient rights. The role needed would have been one of the following:
-
sysadmin
-
db_owner
-
db_ddladmin
If you don’t have sufficient permissions then you aren’t able to use stats, and this is killing your performance across that linked server connections. So for everyone that has been assigning the db_datareader role to remote logins you are sacrificing performance for security. While that may be an acceptable tradeoff in your shop, I am willing to wager that most admins have no idea about this silent performance killer.
A good example of identifying these symptoms are contained in this article:
http://www.sql-server-performance.com/2006/api-server-cursors/
In SQL 2012 SP1 the permissions to view the statistics on an object have been modified so that a user with SELECT permission would be able to use the stats on the remote tables.
Check this link for more details in the ‘Permissions’ section towards the bottom
.
?
---------------------------------------------------------------------------------------------------
2：安全問題
??? 濫用鏈接服務器會導致一個數(shù)據(jù)庫實例跟N個數(shù)據(jù)庫實例之間建立Linked Server，導致數(shù)據(jù)庫管理、監(jiān)控的變得越來越復雜，管理問題是一個，另外一個則是數(shù)據(jù)庫的安全問題。這個最是頭痛。
?
參考資料：
http://www.dbnewsfeed.com/2012/09/08/5-performance-killers-when-working-with-linked-servers/
http://thomaslarock.com/2013/05/top-3-performance-killers-for-linked-server-queries/
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
