2010-09-29 31 views
6

Tôi có một chế độ xem phức tạp mà tôi sử dụng để kéo danh sách các khóa chính cho biết các hàng trong bảng đã được sửa đổi giữa hai điểm thời gian.Tham gia vào các chế độ xem trong SQLServer với hành vi tối ưu hóa truy vấn lạ

Chế độ xem này phải truy vấn 13 bảng có liên quan và xem bảng thay đổi để xác định xem thực thể có "bẩn" hay không.

Ngay cả với tất cả những điều này xảy ra, làm một truy vấn đơn giản:

select * from vwDirtyEntities; 

chỉ mất 2 giây.

Tuy nhiên, nếu tôi thay đổi nó để

select 
    e.Name 
from 
    Entities e 
     inner join vwDirtyEntities de 
      on e.Entity_ID = de.Entity_ID 

này mất vài phút 1.5.

Tuy nhiên, nếu tôi làm điều này:

declare @dirtyEntities table 
(
    Entity_id uniqueidentifier; 
) 

insert into @dirtyEntities 
    select * from vwDirtyEntities; 


select 
    e.Name 
from 
    Entities e 
     inner join @dirtyEntities de 
      on e.Entity_ID = de.Entity_ID 

tôi nhận được kết quả tương tự chỉ trong 2 giây.

Điều này dẫn tôi tin rằng SQLServer đang đánh giá chế độ xem mỗi hàng khi được nối với Thực thể thay vì xây dựng kế hoạch truy vấn liên quan đến việc nối kết bên trong duy nhất ở trên với các kết nối khác trong chế độ xem.

Lưu ý rằng tôi muốn tham gia vào tập hợp kết quả đầy đủ từ chế độ xem này vì nó chỉ lọc ra các khóa tôi muốn trong nội bộ.

Tôi biết tôi có thể biến nó thành khung nhìn vật chất, nhưng điều này sẽ liên quan đến lược đồ ràng buộc chế độ xem và phụ thuộc của nó và tôi không thích chi phí duy trì chỉ mục sẽ gây ra (Chế độ xem này chỉ được truy vấn khi xuất được viết nhiều hơn cho các bảng bên dưới). Vì vậy, ngoài việc sử dụng một biến bảng để lưu vào bộ nhớ cache kết quả xem, có cách nào để nói cho SQL Server để bộ nhớ cache xem trong khi đánh giá tham gia không? Không. Tôi đã thử thay đổi thứ tự tham gia (Chọn từ chế độ xem và tham gia chống lại các thực thể), tuy nhiên điều đó không tạo ra bất kỳ sự khác biệt nào.

Chế độ xem cũng rất hiệu quả và không có chỗ để tối ưu hóa ở đó.

Trả lời

5

Không có gì huyền diệu về chế độ xem. Đó là một macro mở rộng. Trình tối ưu hóa quyết định khi JOINed để mở rộng khung nhìn vào truy vấn chính.

tôi sẽ giải quyết các điểm khác trong bài viết của bạn:

  • bạn đã loại trừ khả năng một cái nhìn lập chỉ mục. Chế độ xem chỉ có thể là một thực thể riêng biệt khi được lập chỉ mục

  • Máy chủ SQL sẽ không bao giờ thực hiện truy vấn RBAR trên chính nó. Chỉ các nhà phát triển mới có thể viết các vòng lặp.

  • không có khái niệm về bộ nhớ đệm: mỗi truy vấn sử dụng dữ liệu mới nhất, trừ khi bạn sử dụng bảng tạm

  • bạn nhấn mạnh vào sử dụng giao diện mà bạn đã quyết định là rất hiệu quả.Nhưng không có ý tưởng như thế nào xem được xử lý bằng các ưu và nó có bảng

  • SQL là khai báo: để tham gia thường không quan trọng

  • Nhiều nhà phát triển DB nghiêm trọng không sử dụng quan điểm vì những hạn chế như thế này: chúng không thể tái sử dụng được vì chúng là các macro

Chỉnh sửa, một khả năng khác. Predicate pushing trên SQL Server 2005. Tức là, SQL Server không thể đẩy điều kiện JOIN "sâu hơn" vào chế độ xem.

+0

Nếu bạn nhìn vào lịch sử chỉnh sửa bài đăng cho Omg Ponies, bạn sẽ thấy rằng tôi đã trả lời bằng một nhận xét đơn giản (vẫn ở đó), và anh ấy đã không còn lo lắng. Đối với ngữ cảnh, đây là câu trả lời ban đầu của anh ấy: http://stackoverflow.com/revisions/2be5678d-7d09-4c14-9043-c4769f9f9c03/view-source. – FlySwat

+0

Và đây là chỉnh sửa mà anh ta đã làm sau nhận xét của tôi: http://stackoverflow.com/revisions/0d5a1cb1-1f89-4fba-96f4-c270d0543805/view-source. Tôi chưa bao giờ tấn công anh ta, anh ta bắt đầu lật ra. – FlySwat

+0

Về thứ tự tham gia không quan trọng. Điều đó có thể đúng theo lý thuyết, nhưng trong thực tế tôi đã thấy rõ ràng việc sắp xếp lại các tham gia có lợi, thường là vì nó cho phép cơ sở dữ liệu loại bỏ các tập dữ liệu lớn hơn mà không khớp trước khi đánh giá các phép nối khác. – FlySwat

Các vấn đề liên quan