Là một cái nhìn nhanh hơn một truy vấn đơn giản?

Là một

select *  from myView

nhanh hơn chính truy vấn để tạo chế độ xem (để có cùng kết quả):

select * from ([query to create same resultSet as myView])

?

Nó không hoàn toàn rõ ràng với tôi nếu chế độ xem sử dụng một số loại bộ nhớ đệm làm cho nó nhanh hơn so với một truy vấn đơn giản.

Có , các chế độ xem có thể có một chỉ mục được gán và khi chúng thực hiện, chúng sẽ lưu trữ các kết quả tạm thời có thể tăng tốc các truy vấn kết quả.

Cập nhật: Ít nhất ba người đã bỏ phiếu cho tôi về điều này. Với tất cả sự tôn trọng, tôi nghĩ rằng họ chỉ sai; Tài liệu riêng của Microsoft cho thấy rất rõ rằng Lượt xem có thể cải thiện hiệu suất.

Đầu tiên, các chế độ xem đơn giản được mở rộng tại chỗ và do đó không trực tiếp đóng góp vào cải tiến hiệu suất - điều đó là đúng. Tuy nhiên, quan điểm được lập chỉ mục có thể cải thiện đáng kể hiệu suất.

Hãy để tôi đi trực tiếp đến tài liệu:

Sau khi một chỉ mục cụm duy nhất được tạo trên chế độ xem, tập kết quả của chế độ xem được cụ thể hóa ngay lập tức và được lưu trữ trong bộ lưu trữ vật lý trong cơ sở dữ liệu, tiết kiệm chi phí thực hiện thao tác tốn kém này trong thời gian thực hiện.

Thứ hai, các khung nhìn được lập chỉ mục này có thể hoạt động ngay cả khi chúng không được tham chiếu trực tiếp bởi một truy vấn khác vì trình tối ưu hóa sẽ sử dụng chúng thay cho tham chiếu bảng khi thích hợp.

Một lần nữa, tài liệu:

Chế độ xem được lập chỉ mục có thể được sử dụng trong thực hiện truy vấn theo hai cách. Truy vấn có thể tham chiếu trực tiếp chế độ xem được lập chỉ mục hoặc quan trọng hơn là trình tối ưu hóa truy vấn có thể chọn chế độ xem nếu xác định rằng chế độ xem có thể được thay thế cho một số hoặc tất cả truy vấn trong gói truy vấn chi phí thấp nhất. Trong trường hợp thứ hai, khung nhìn được lập chỉ mục được sử dụng thay cho các bảng bên dưới và các chỉ mục thông thường của chúng. Khung nhìn không cần phải được tham chiếu trong truy vấn để trình tối ưu hóa truy vấn sử dụng nó trong khi thực hiện truy vấn. Điều này cho phép các ứng dụng hiện có được hưởng lợi từ các khung nhìn được lập chỉ mục mới được tạo mà không thay đổi các ứng dụng đó.

Tài liệu này, cũng như các biểu đồ thể hiện sự cải thiện hiệu suất, có thể được tìm thấy ở đây .

Cập nhật 2: câu trả lời đã bị chỉ trích trên cơ sở rằng đó là "chỉ mục" cung cấp lợi thế về hiệu suất, chứ không phải là "Chế độ xem". Tuy nhiên, điều này dễ dàng bị bác bỏ.

Hãy để chúng tôi nói rằng chúng tôi là một công ty phần mềm ở một quốc gia nhỏ; Tôi sẽ sử dụng Litva làm ví dụ. Chúng tôi bán phần mềm trên toàn thế giới và lưu giữ hồ sơ của chúng tôi trong cơ sở dữ liệu SQL Server. Chúng tôi rất thành công và vì vậy, trong một vài năm, chúng tôi có hơn 1.000.000 hồ sơ. Tuy nhiên, chúng tôi thường cần báo cáo doanh số vì mục đích thuế và chúng tôi thấy rằng chúng tôi chỉ bán được 100 bản sao phần mềm tại quốc gia của chúng tôi. Bằng cách tạo chế độ xem được lập chỉ mục cho các bản ghi Litva, chúng tôi có thể giữ các bản ghi chúng tôi cần trong bộ đệm được lập chỉ mục như được mô tả trong tài liệu MS. Khi chúng tôi chạy các báo cáo về doanh số bán hàng của Litva năm 2008, truy vấn của chúng tôi sẽ tìm kiếm thông qua một chỉ mục với độ sâu chỉ 7 (Log2 (100) với một số lá chưa sử dụng). Nếu chúng ta làm tương tự mà không cần XEM và chỉ dựa vào một chỉ mục vào bảng, chúng ta sẽ phải duyệt qua một cây chỉ mục với độ sâu tìm kiếm là 21!

Rõ ràng, chính View sẽ cung cấp cho chúng ta lợi thế về hiệu suất (3x) so với việc sử dụng chỉ mục đơn giản. Tôi đã thử sử dụng một ví dụ trong thế giới thực nhưng bạn sẽ lưu ý rằng một danh sách đơn giản về doanh số bán hàng của Litva sẽ mang lại cho chúng tôi một lợi thế lớn hơn nữa.

Lưu ý rằng tôi chỉ sử dụng cây b thẳng cho ví dụ của mình. Mặc dù tôi khá chắc chắn rằng SQL Server sử dụng một số biến thể của cây b, tôi không biết chi tiết. Tuy nhiên, điểm giữ.

Cập nhật 3: Câu hỏi đã được đưa ra về việc liệu Chế độ xem được lập chỉ mục có sử dụng một chỉ mục được đặt trên bảng bên dưới hay không. Đó là, để diễn giải: "một chế độ xem được lập chỉ mục chỉ tương đương với một chỉ mục tiêu chuẩn và nó không cung cấp gì mới hoặc duy nhất cho một chế độ xem". Nếu điều này là đúng, tất nhiên, thì phân tích trên sẽ không chính xác! Hãy để tôi cung cấp một trích dẫn từ tài liệu của Microsoft chứng minh lý do tại sao tôi nghĩ rằng lời chỉ trích này không hợp lệ hoặc đúng:

Sử dụng các chỉ mục để cải thiện hiệu năng truy vấn không phải là một khái niệm mới; tuy nhiên, các khung nhìn được lập chỉ mục cung cấp các lợi ích hiệu suất bổ sung không thể đạt được bằng cách sử dụng các chỉ mục tiêu chuẩn.

Cùng với trích dẫn ở trên liên quan đến sự tồn tại của dữ liệu trong bộ lưu trữ vật lý và các thông tin khác trong tài liệu về cách tạo các chỉ mục trên Chế độ xem, tôi nghĩ rằng có thể an toàn khi nói rằng Chế độ xem được lập chỉ mục không phải là SQL Chọn được lưu trong bộ nhớ cache. chỉ số được xác định trên bảng chính. Vì vậy, tôi tiếp tục đứng trước câu trả lời này.

Nói chung là không. Lượt xem chủ yếu được sử dụng để thuận tiện và bảo mật và sẽ không (tự chúng) tạo ra bất kỳ lợi ích tốc độ nào.

Điều đó nói rằng, SQL Server 2000 trở lên có một tính năng gọi là Indexed xem rằng có thể cải thiện đáng kể hiệu suất, với một vài hãy cẩn thận:

1. Không phải mọi khung nhìn đều có thể được tạo thành một khung nhìn được lập chỉ mục; họ phải tuân theo một tập hợp cụ thể các chủ trương , mà (trong số những hạn chế khác) có nghĩa là bạn không thể bao gồm các yếu tố truy vấn phổ biến như COUNT, MIN, MAX, hoặc TOP.
2. Các khung nhìn được lập chỉ mục sử dụng không gian vật lý trong cơ sở dữ liệu, giống như các chỉ mục trên một bảng.

Bài viết này mô tả các lợi ích và hạn chế bổ sung của các khung nhìn được lập chỉ mục :

Bạn có thể…

• Định nghĩa khung nhìn có thể tham chiếu một hoặc nhiều bảng trong cùng một cơ sở dữ liệu.
• Khi chỉ mục cụm duy nhất được tạo, các chỉ mục không bao gồm bổ sung có thể được tạo theo chế độ xem.
• Bạn có thể cập nhật dữ liệu trong các bảng bên dưới - bao gồm chèn, cập nhật, xóa và thậm chí cắt ngắn.

Bạn không thể

• Định nghĩa khung nhìn không thể tham chiếu các khung nhìn khác hoặc các bảng trong cơ sở dữ liệu khác.
• Nó không thể chứa COUNT, MIN, MAX, TOP, các phép nối ngoài hoặc một vài từ khóa hoặc thành phần khác.
• Bạn không thể sửa đổi các bảng và cột bên dưới. Khung nhìn được tạo ra với tùy chọn VỚI SCHEMABINDING.
• Bạn không thể luôn dự đoán những gì trình tối ưu hóa truy vấn sẽ làm. Nếu bạn đang sử dụng Phiên bản doanh nghiệp, nó sẽ tự động coi chỉ mục được nhóm duy nhất là một tùy chọn cho truy vấn - nhưng nếu nó tìm thấy một chỉ mục tốt hơn, thì nó sẽ được sử dụng. Bạn có thể buộc trình tối ưu hóa sử dụng chỉ mục thông qua gợi ý VỚI NOEXPAND - nhưng hãy thận trọng khi sử dụng bất kỳ gợi ý nào.

Trong SQL Server ít nhất, các gói truy vấn được lưu trữ trong bộ đệm của kế hoạch cho cả các khung nhìn và các truy vấn SQL thông thường, dựa trên các tham số truy vấn / khung nhìn. Đối với cả hai, chúng được loại bỏ khỏi bộ đệm khi chúng không được sử dụng trong một khoảng thời gian đủ dài và không gian cần thiết cho một số truy vấn mới được gửi khác. Sau đó, nếu cùng một truy vấn được đưa ra, nó sẽ được biên dịch lại và kế hoạch được đưa trở lại vào bộ đệm. Vì vậy, không có sự khác biệt, cho rằng bạn đang sử dụng lại cùng một truy vấn SQL và cùng một chế độ xem với cùng tần số.

Rõ ràng, nói chung, một quan điểm, bởi chính bản chất của nó (Rằng ai đó nghĩ rằng nó thường được sử dụng đủ để biến nó thành một khung nhìn) thường có khả năng được "tái sử dụng" hơn bất kỳ câu lệnh SQL tùy ý nào.

EDIT: Tôi đã sai, và bạn sẽ thấy Marks trả lời ở trên.

Tôi không thể nói từ kinh nghiệm với SQL Server , nhưng đối với hầu hết các cơ sở dữ liệu, câu trả lời sẽ là không. Lợi ích tiềm năng duy nhất mà bạn nhận được, hiệu suất khôn ngoan, từ việc sử dụng chế độ xem là nó có khả năng tạo ra một số đường dẫn truy cập dựa trên truy vấn. Nhưng lý do chính để sử dụng chế độ xem là để đơn giản hóa truy vấn hoặc chuẩn hóa cách truy cập một số dữ liệu trong bảng. Nói chung, bạn sẽ không nhận được lợi ích hiệu suất. Tôi có thể đã sai.

Tôi sẽ đưa ra một ví dụ phức tạp hơn vừa phải và tự mình xem nó.

Nó có thể nhanh hơn nếu bạn tạo một khung nhìn cụ thể hóa ( với ràng buộc lược đồ ). Các khung nhìn phi vật chất thực hiện giống như truy vấn thông thường.

Tôi hiểu rằng một thời gian trước, một khung nhìn sẽ nhanh hơn vì SQL Server có thể lưu trữ một kế hoạch thực hiện và sau đó chỉ sử dụng nó thay vì cố gắng tìm ra một cách nhanh chóng. Tôi nghĩ rằng hiệu suất tăng hiện nay có lẽ không còn như trước đây, nhưng tôi phải đoán sẽ có một số cải tiến nhỏ để sử dụng chế độ xem.

Chắc chắn một khung nhìn tốt hơn một truy vấn lồng nhau cho SQL Server. Không biết chính xác lý do tại sao nó tốt hơn (cho đến khi tôi đọc bài đăng của Mark Britsham), tôi đã chạy một số thử nghiệm và trải nghiệm các cải tiến hiệu suất gần như gây sốc khi sử dụng chế độ xem so với truy vấn lồng nhau. Sau khi chạy từng phiên bản của truy vấn vài trăm lần liên tiếp, phiên bản xem của truy vấn đã hoàn thành trong một nửa thời gian. Tôi muốn nói rằng đó là bằng chứng đủ cho tôi.

Tôi mong đợi hai truy vấn sẽ thực hiện giống hệt nhau. Một khung nhìn không có gì khác hơn là một định nghĩa truy vấn được lưu trữ, không có bộ nhớ đệm hoặc lưu trữ dữ liệu cho một khung nhìn. Trình tối ưu hóa sẽ thực sự biến truy vấn đầu tiên của bạn thành truy vấn thứ hai khi bạn chạy nó.

Tất cả phụ thuộc vào tình hình. MS SQL Các khung nhìn được lập chỉ mục nhanh hơn một khung nhìn hoặc truy vấn thông thường nhưng các khung nhìn được lập chỉ mục không thể được sử dụng trong một cơ sở dữ liệu được nhân đôi (MS SQL).

Một khung nhìn trong bất kỳ loại vòng lặp nào cũng sẽ gây ra sự chậm lại nghiêm trọng vì chế độ xem được lặp lại mỗi lần nó được gọi trong vòng lặp. Tương tự như một truy vấn. Trong tình huống này, một bảng tạm thời sử dụng # hoặc @ để giữ dữ liệu của bạn lặp lại nhanh hơn so với chế độ xem hoặc truy vấn.

Vì vậy, tất cả phụ thuộc vào tình hình.

Không có sự khác biệt thực tế nào và nếu bạn đọc BOL, bạn sẽ thấy rằng bao giờ SQL SQL cũ * TỪ X của bạn tận dụng lợi thế của bộ nhớ đệm kế hoạch, v.v.

Cần có một số lợi ích không đáng kể trong việc lưu trữ kế hoạch thực hiện, nhưng nó sẽ không đáng kể.

Mục đích của một khung nhìn là sử dụng truy vấn nhiều lần. Cuối cùng, SQL Server, Oracle, v.v. thường sẽ cung cấp phiên bản "được lưu trong bộ nhớ cache" hoặc "đã biên dịch" cho chế độ xem của bạn, do đó cải thiện hiệu suất của nó. Nói chung, điều này sẽ thực hiện tốt hơn một truy vấn "đơn giản", mặc dù nếu truy vấn đó thực sự rất đơn giản, lợi ích có thể không đáng kể.

Bây giờ, nếu bạn đang thực hiện một truy vấn phức tạp, hãy tạo chế độ xem.

Trong tìm kiếm của tôi, sử dụng chế độ xem nhanh hơn một chút so với truy vấn thông thường. Quy trình được lưu trữ của tôi mất khoảng 25 phút (làm việc với một bộ bản ghi lớn hơn và nhiều phép nối khác nhau) và sau khi sử dụng chế độ xem (không phân cụm), hiệu suất chỉ nhanh hơn một chút nhưng không đáng kể. Tôi đã phải sử dụng một số kỹ thuật / phương pháp tối ưu hóa truy vấn khác để làm cho nó thay đổi đáng kể.

Chọn từ Chế độ xem hoặc từ bảng sẽ không có ý nghĩa quá nhiều.

Tất nhiên, nếu Chế độ xem không có các phép nối, trường không cần thiết, v.v. Bạn có thể kiểm tra kế hoạch thực hiện các truy vấn, tham gia và chỉ mục của mình được sử dụng để cải thiện hiệu suất Xem.

Bạn thậm chí có thể tạo chỉ mục trên lượt xem cho các yêu cầu tìm kiếm nhanh hơn. http://technet.microsoft.com/en-us/l Library / cc917715.aspx

Nhưng nếu bạn đang tìm kiếm như '% ...%' thì công cụ sql sẽ không được hưởng lợi từ một chỉ mục trên cột văn bản. Nếu bạn có thể buộc người dùng của mình thực hiện các tìm kiếm như '...%' thì sẽ nhanh hơn

tham khảo câu trả lời trên các diễn đàn asp: https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+USE+SELECT+query+VIEW+or+Table+

Chống lại tất cả các kỳ vọng, quan điểm là cách chậm hơn trong một số trường hợp.

Tôi phát hiện ra điều này gần đây khi tôi gặp vấn đề với dữ liệu được lấy từ Oracle cần được mát xa sang định dạng khác. Có thể hàng 20k nguồn. Một cái bàn nhỏ. Để làm điều này, chúng tôi đã nhập dữ liệu orory không thay đổi nhất có thể vào một bảng và sau đó sử dụng các khung nhìn để trích xuất dữ liệu. Chúng tôi đã có quan điểm thứ cấp dựa trên những quan điểm đó. Có thể 3-4 cấp độ xem.

Một trong những truy vấn cuối cùng, có thể trích xuất có thể 200 hàng sẽ mất tới 45 phút! Truy vấn đó được dựa trên một loạt các lượt xem. Có thể sâu 3-4 cấp.

Tôi có thể lấy từng khung nhìn trong câu hỏi, chèn sql của nó vào một truy vấn lồng nhau và thực hiện nó trong vài giây.

Chúng tôi thậm chí còn thấy rằng chúng tôi thậm chí có thể viết từng chế độ xem vào một bảng tạm thời và truy vấn thay cho chế độ xem và nó vẫn nhanh hơn so với việc sử dụng các chế độ xem lồng nhau.

Điều thậm chí còn kỳ quặc hơn là hiệu suất vẫn ổn cho đến khi chúng tôi đạt được một số giới hạn của các hàng nguồn được kéo vào cơ sở dữ liệu, các hiệu suất chỉ rơi xuống một vách đá trong không gian của một vài ngày - tất cả các hàng nguồn khác đã mất.

Vì vậy, việc sử dụng các truy vấn lấy từ các lượt xem kéo từ các lượt xem chậm hơn nhiều so với truy vấn lồng nhau - điều này không có ý nghĩa đối với tôi.

Tôi đã chạy qua chủ đề này và chỉ muốn chia sẻ bài đăng này từ Brent Ozar như một cái gì đó để xem xét khi sử dụng các nhóm sẵn có.

Báo cáo lỗi Brent Ozar