Ý nghĩa về hiệu suất của việc sử dụng OPENQUERY trong chế độ xem

Vui lòng xem câu hỏi này trên stackoverflow:

Tôi đang sử dụng trình điều khiển EasySoft ODBC để liên kết phiên bản SQL Server 2008 R2 Express với Interbase và tôi gặp một số khó khăn khi nhận siêu dữ liệu từ máy chủ từ xa. Từ việc tìm kiếm trên mạng, tất cả các loại đường chính đều đề cập đến việc sử dụng OPENQUERY thay vì cú pháp máy chủ được liên kết bốn phần.

EG Cách tiếp cận hiện tại (có vấn đề) của tôi là ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

SELECT *
FROM [LBLIVE]...[PRDETS] WITH (NOLOCK)

Nhưng trên một số bảng tôi gặp lỗi khi gọi chế độ xem ...

Msg 7353, Cấp 16, Trạng thái 1, Dòng 1 Nhà cung cấp OLE DB "MSDASQL" cho máy chủ được liên kết "LBLIVE" cung cấp siêu dữ liệu không nhất quán. Một cột bổ sung đã được cung cấp trong quá trình thực thi không được tìm thấy tại thời điểm biên dịch.

Ngoài ra, một số chế độ xem tôi thậm chí không thể tạo vì tôi nhận được ...

Msg 7315, Cấp 16, Trạng thái 1, Dòng 1 Nhà cung cấp OLE DB "MSDASQL" cho máy chủ được liên kết "LBLIVE" chứa nhiều bảng khớp với tên "" SYSDBA "." AUDIT_LBABKP "".

Mặc dù chỉ có một trong các bảng được đề cập.

Cách tiếp cận khác từ tìm kiếm trên mạng dường như giống ...

SELECT *
FROM OPENQUERY(<linked sevrer>, 'SELECT <column list> FROM MyTable')

Vì vậy, câu hỏi của tôi là, nếu tôi sử dụng OPENQUERY trong định nghĩa chế độ xem của mình, SQL Server có thể tối ưu hóa kết quả SQL được gửi đến Interbase không? Hay thực sự không có nhiều khác biệt giữa hai cách tiếp cận?

Đó là một chủ đề xuyên suốt và sẽ yêu POV của dba.

Tóm lược

Hãy để máy chủ được liên kết làm càng nhiều càng tốt.
Nó là không thể cho SQL Server để tối ưu hóa một truy vấn trên một máy chủ được liên kết, thậm chí khác SQL Server

Dài

Yếu tố then chốt là nơi truy vấn chạy.

Trong trường hợp này, nó là một CHỌN tầm thường để tất cả các hàng từ một bảng sẽ được gửi xuống dây. Nó không thành vấn đề.

Khi bạn thêm THAM GIA và WHERE thì nó có thể quan trọng. Bạn muốn SQL Server cho phép máy chủ được liên kết thực hiện lọc càng nhiều càng tốt để giảm kích thước của dữ liệu qua mạng.

Ví dụ, trường hợp thứ 2 ở đây sẽ hiệu quả hơn.

SELECT *
FROM OPENQUERY(<linked server>, 
            'SELECT <column list> FROM MyTable') T1
     JOIN
     SomeLocalTable T2 ON ...
WHERE T1.foo = 'bar'

SELECT *
FROM OPENQUERY(<linked server>, 
           'SELECT <column list> FROM MyTable WHERE foo = ''bar''')
     JOIN
     SomeLocalTable T2 ON ...

Một hạn chế của OPENQUERY là bạn không thể tham gia: vì vậy bạn cần SQL động để thêm các mệnh đề WHERE, v.v.

Hiệu suất máy chủ liên kết có thể bị ảnh hưởng bởi sp_serveroption. Các thiết lập collation compatiblenói lên tất cả

Nếu tùy chọn này được đặt thành true, SQL Server giả định rằng tất cả các ký tự trong máy chủ được liên kết đều tương thích với máy chủ cục bộ, liên quan đến bộ ký tự và trình tự đối chiếu (hoặc thứ tự sắp xếp). Điều này cho phép SQL Server gửi các so sánh trên các cột ký tự cho nhà cung cấp. Nếu tùy chọn này không được đặt, SQL Server luôn đánh giá các so sánh trên các cột ký tự cục bộ.

Đó là, cố gắng không để SQL Server xử lý dữ liệu cục bộ.

Lưu ý: Trong foo = 'bar'ví dụ thứ 2 của tôi ở trên, bộ lọc được gửi đến máy chủ được liên kết vì nó chỉ là một chuỗi hằng số cho SQL Server. Mệnh đề WHERE thực trong ví dụ đầu tiên có thể được gửi từ xa.

Cuối cùng, tôi cũng thấy rằng việc sắp xếp dữ liệu vào một bảng tạm thời và nối nó vào các bảng cục bộ thường tốt hơn sau đó tham gia trực tiếp vào OPENQUERY.