2012-04-23 30 views
12

Trong SQL Server 2008 tôi có một cái nhìn V trên bảng AB trông gần nhưSQL Server biết cách khóa các đối tượng xem?

create view V as 
    select * from A 
    union all 
    select * from B 

Đọc từ V gây ra một truy vấn để lấy khóa chia sẻ ý định trên các bảng cơ sở, nhưng cũng phải mất một khóa chia sẻ ý định trên đối tượng xem. Rõ ràng lý do tại sao chúng ta cần các khóa IS trên các bảng và chúng ta có thể thấy rằng khóa IS trên khung nhìn ngăn không cho sửa đổi đồng thời với các bảng nằm bên dưới khung nhìn. Đó là tốt.

Gói truy vấn không chứa đề cập đến chế độ xem. Nó hoàn toàn được biên dịch, và kế hoạch kết quả trong trường hợp này là một phép nối đơn giản các hàng từ hai bảng cơ sở. Thật vậy, đề cập duy nhất về khung nhìn trong XML kế hoạch truy vấn nằm trong văn bản câu lệnh.

Nếu bạn thêm chế độ xem thứ hai U qua các bảng, hãy đọc từ V không gây ra bất kỳ khóa nào được thực hiện trên U. Quy tắc này cho biết động cơ chỉ cần khóa IS trên tất cả các chế độ xem trên AB.

Làm cách nào để cơ sở dữ liệu biết khóa trên chế độ xem?

  • Văn bản câu lệnh có được phân tích cú pháp lần nữa không?
  • Có một số kênh thông tin khác giữa trình lập kế hoạch truy vấn và thực thi cơ bản để chuyển thông tin này không?

Xem corresponding question on dba.stackexchange để biết thêm chi tiết.

+0

Có lẽ nó bắt đầu bằng cách khóa chế độ xem để ngăn thay đổi thiết kế cho chế độ xem trong khi đang được sử dụng. – JamieSee

+0

@JamieSee, nó sẽ mất một S od Sch-M khóa, sau đó. – usr

+1

Gói thực hiện được lưu trữ ở định dạng nhị phân. Không phải mọi thứ mà nó chứa đều được thể hiện trong XML được hiển thị cho chúng tôi. –

Trả lời

0

Theo mặc định, chế độ xem được mở rộng, như macro, vào các truy vấn tham chiếu đến chúng.

Điều này có thể bị tắt hoặc thay đổi nếu chúng được vật chất hóa, v.v ... nhưng việc mở rộng nội dòng giống macro là chuẩn. Điều này có nghĩa rằng khóa, vv, cư xử như thể bạn đã sau ...

SELECT 
    * 
FROM 
    blah 
INNER JOIN 
(
    yourViewCode 
) 
    AS aView 
    ON aView.id = blh.id 
+1

Nhưng nó ** không ** hành xử như thế này. – usr

+2

Và điều này có thể là một sự thuận tiện tốt đẹp cho sự hiểu biết, nhưng quan điểm được biên dịch khi chúng được tạo ra. Nếu các bảng bên dưới thay đổi, các khung nhìn sẽ không, bằng defalt, được thay đổi. Cụ thể, bạn nên tránh "chọn *" trong chế độ xem vì lý do này. –

+0

@Dường Tôi biết rằng chế độ xem được mở rộng như thế này và tôi không nói về hành vi bên ngoài tiêu chuẩn này hoặc lượt xem vật chất hóa. Trong mọi trường hợp, như usr chỉ ra, đó không phải là hành vi mà tôi hỏi. –

2

Nếu bạn nhìn vào quan điểm sys.dm_exec_query_optimizer_info, mà trả về chi tiết của tôi ưu truy vấn SQL Server, một trong những chi tiết trở lại như sau lĩnh vực:

tham chiếu chế độ xem - Số lượt xem đã được tham chiếu trong truy vấn.

Có vẻ như số lần mà một cái nhìn được tham chiếu được theo dõi đâu đó, có thể là một phần của kế hoạch thực hiện ... giả định của tôi là ngay cả khi quan điểm được mở rộng, kế hoạch thực hiện vẫn chứa chi tiết về chế độ xem nào được sử dụng trong truy vấn và đưa ra các khóa IS phù hợp với các chế độ xem được tham chiếu này.

+1

Có thể có ý nghĩa hơn nếu có một cấu trúc dữ liệu riêng biệt cho những phụ thuộc này, do đó nó không phải quét toàn bộ bộ đệm kế hoạch khi các đối tượng phụ thuộc bị thay đổi. Đừng nghĩ rằng mức độ nội bộ này được ghi lại ở bất cứ đâu. –

+0

@MartinSmith Tôi nghĩ rằng bạn đúng ... giống như bình luận của bạn cho câu hỏi được đề cập, những phụ thuộc này có thể được đưa vào phần nhị phân của kế hoạch thực hiện. Tôi đã tìm kiếm một lúc, và DMV này là tài liệu tham khảo duy nhất tôi có thể thấy rằng từ xa đã giải quyết vấn đề này. –

+0

@MichaelFredrickson yeah đó là một khởi đầu tốt, cảm ơn vì đã tìm ra điều đó. Tôi thực sự muốn biết nếu nó được ghi lại bất cứ nơi nào mà khóa này trên xem được thực hiện, và đặc biệt tôi sẽ không xem xét đó là một chi tiết thực hiện nội bộ. Hoàn toàn ngược lại - các khóa được lấy sẽ có vẻ là một phần rõ ràng của ngữ nghĩa đọc qua khung nhìn. –

3

sao chép từ my answer on dba.stackexchange:

Từ Conor Cunningham, nguồn gốc tối hậu của bất cứ điều gì cụ tìm hoặc tối ưu hóa liên quan đến:

Chúng tôi theo dõi mọi thứ trong biên dịch để kiểm tra khi chạy. Chúng tôi không phân tích cú pháp việc thực hiện cho mục đích này.

Lưu ý: nội bộ của những gì chúng tôi làm từ bản phát hành này sang bản phát hành khác không được bảo đảm . Đây là bên dưới khu vực bề mặt được hỗ trợ chính thức.

Niềm tin của tôi là phiên bản nhị phân của kế hoạch thực hiện (không phải là có thể đọc được và tiếp xúc với chúng tôi qua XML, chỉ là một tập hợp con của phiên bản nhị phân) phải chứa một số con trỏ đến khung nhìn) được tham chiếu trong văn bản truy vấn gốc (và điều này được ám chỉ ở trên). Rõ ràng là không phân tích cú pháp văn bản truy vấn mỗi lần. Conor ngụ ý nhiều như trên, nhưng cẩn thận không tiết lộ bất kỳ chi tiết nào về vị trí hoặc cách lưu trữ, vì điều này có khả năng thay đổi từ bản phát hành sang bản phát hành hoặc thậm chí với gói dịch vụ hoặc bản cập nhật tích luỹ. Có lẽ anh cũng không muốn khuyến khích bất kỳ công việc thám tử nào. :-)

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