Hiệu suất của SQL Server Linked Server: Tại sao các truy vấn từ xa lại đắt như vậy?

Tôi có hai máy chủ cơ sở dữ liệu, được kết nối qua Máy chủ được liên kết. Cả hai đều là cơ sở dữ liệu SQL Server 2008R2 và kết nối máy chủ được liên kết được thực hiện thông qua liên kết "Máy chủ SQL" thông thường, sử dụng bối cảnh bảo mật của thông tin đăng nhập hiện tại. Các máy chủ được liên kết đều ở cùng một trung tâm dữ liệu, vì vậy kết nối không phải là vấn đề.

Tôi sử dụng truy vấn sau đây để kiểm tra giá trị nào của cột identifiercó sẵn từ xa, nhưng không phải cục bộ.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT DISTINCT
    identifier 
FROM LocalDb.schema.[TableName] 

Trên cả hai bảng là các chỉ mục không được nhóm trên cột identifier. Tại địa phương có khoảng 2,6 triệu hàng, chỉ từ xa 54. Tuy nhiên, khi nhìn vào kế hoạch truy vấn, 70% thời gian thực hiện được dành cho "thực hiện truy vấn từ xa". Ngoài ra, khi nghiên cứu kế hoạch truy vấn hoàn chỉnh, số lượng các hàng cục bộ ước tính 1thay vì 2695380(là số lượng các hàng ước tính khi chỉ chọn truy vấn đến sau EXCEPT). Khi thực hiện truy vấn này, thực sự phải mất một thời gian dài.

Nó làm tôi tự hỏi: Tại sao lại thế này? Là ước tính "chỉ" cách, hoặc các truy vấn từ xa trên các máy chủ được liên kết thực sự đắt tiền?

Kế hoạch bạn có vào lúc này có vẻ như là kế hoạch tối ưu nhất với tôi.

Tôi không đồng ý với khẳng định trong các câu trả lời khác rằng nó đang gửi các hàng 2,6M đến máy chủ từ xa.

Kế hoạch đối với tôi như thể đối với mỗi trong số 54 hàng được trả về từ truy vấn từ xa, nó đang thực hiện một tìm kiếm chỉ mục vào bảng cục bộ của bạn để xác định xem nó có khớp hay không. Đây là khá nhiều kế hoạch tối ưu.

Thay thế bằng phép nối băm hoặc phép nối hợp nhất sẽ phản tác dụng với kích thước của bảng và thêm #tempbảng trung gian chỉ cần thêm một bước bổ sung dường như không mang lại cho bạn bất kỳ lợi thế nào.

Kết nối với một tài nguyên từ xa là tốn kém. Giai đoạn = Stage.

Một trong những hoạt động đắt nhất trong bất kỳ môi trường lập trình nào là IO mạng (mặc dù IO đĩa có xu hướng lùn nó).

Điều này mở rộng đến các máy chủ được liên kết từ xa. Máy chủ gọi máy chủ được liên kết từ xa trước tiên cần thiết lập kết nối, sau đó truy vấn cần được thực hiện trên máy chủ từ xa, kết quả được trả về và kết nối bị đóng. Tất cả điều này mất thời gian qua mạng.

Bạn cũng nên cấu trúc truy vấn của mình theo cách bạn chuyển dữ liệu tối thiểu qua dây. Đừng mong đợi DB sẽ tối ưu hóa cho bạn.

Nếu tôi viết truy vấn này, tôi sẽ chọn dữ liệu từ xa vào biến bảng (hoặc vào bảng tạm thời) và sau đó sử dụng kết hợp này với bảng cục bộ. Điều này đảm bảo rằng chỉ có dữ liệu cần được chuyển sẽ.

Truy vấn bạn đang chạy có thể dễ dàng gửi các hàng 2,6M đến máy chủ từ xa để xử lý EXCEPTmệnh đề.

Tôi không phải là chuyên gia nhưng nếu bạn đang sử dụng Union, Ngoại trừ hoặc Intersect, bạn không phải sử dụng "Khác biệt". Tùy thuộc vào các giá trị từ LocalDb.schema. [Tên bảng], hiệu suất truy vấn có thể được cải thiện.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT 
    identifier 
FROM LocalDb.schema.[TableName]

Oded là đúng, vấn đề hiệu suất là do gửi các hàng 2,6M đến máy chủ từ xa của bạn.

Để khắc phục sự cố này, bạn có thể buộc dữ liệu từ xa (54 hàng) được gửi cho bạn bằng cách sử dụng tạm thời hoặc trong bảng bộ nhớ.

Sử dụng bảng tạm thời

SELECT  identifier 
INTO    #TableName
FROM    LinkedServer.RemoteDb.schema.[TableName]

SELECT  identifier
FROM    #TableName
EXCEPT
SELECT  DISTINCT identifier 
FROM    LocalDb.schema.[TableName] 

DROP    #TableName

Tôi nghĩ rằng tốt hơn hết là sao chép bảng từ xa vào máy chủ mà bạn đang truy vấn và sau đó chạy tất cả SQL của bạn cục bộ.