Khi nào nên sử dụng lượt xem trong MySQL?

Khi tạo các bảng từ nhiều phép nối để sử dụng trong phân tích, khi nào thì nên sử dụng các khung nhìn so với việc tạo một bảng mới?

Một lý do mà tôi muốn sử dụng các khung nhìn là lược đồ cơ sở dữ liệu đã được quản trị viên của chúng tôi phát triển từ bên trong Ruby và tôi không quen với Ruby. Tôi có thể yêu cầu các bảng được tạo, nhưng yêu cầu một bước bổ sung và tôi muốn linh hoạt hơn khi phát triển / thử nghiệm các phép nối mới.

Tôi bắt đầu sử dụng các khung nhìn theo câu trả lời cho một câu hỏi liên quan trên SO ( Khi nào nên sử dụng R, khi nào nên sử dụng SQL ). Câu trả lời được bình chọn hàng đầu bắt đầu "thực hiện các thao tác dữ liệu trong SQL cho đến khi dữ liệu nằm trong một bảng duy nhất và sau đó thực hiện phần còn lại trong R."

Tôi đã bắt đầu sử dụng lượt xem, nhưng tôi gặp phải một số vấn đề với lượt xem:

1. truy vấn chậm hơn nhiều
2. Lượt xem không được chuyển từ sản xuất sang cơ sở dữ liệu sao lưu mà tôi sử dụng để phân tích.

Là quan điểm thích hợp cho việc sử dụng này? Nếu vậy, tôi có nên mong đợi một hình phạt hiệu suất? Có cách nào để tăng tốc truy vấn về lượt xem không?

Lượt xem trong MySQL được xử lý bằng một trong hai thuật toán khác nhau: MERGEhoặc TEMPTABLE. MERGEchỉ đơn giản là một mở rộng truy vấn với các bí danh thích hợp. TEMPTABLEđúng như những gì nó nghe, khung nhìn đặt kết quả vào một bảng tạm thời trước khi chạy mệnh đề WHERE và không có chỉ mục nào trên đó.

Tùy chọn 'thứ ba' là UNDEFINED, yêu cầu MySQL chọn thuật toán thích hợp. MySQL sẽ cố gắng sử dụng MERGEvì nó hiệu quả hơn. Chính xác:

Nếu thuật toán MERGE không thể được sử dụng, thay vào đó phải sử dụng bảng tạm thời. MERGE không thể được sử dụng nếu chế độ xem chứa bất kỳ cấu trúc nào sau đây:

• Các hàm tổng hợp (SUM (), MIN (), MAX (), COUNT (), v.v.

• KHOẢNG CÁCH

• NHÓM THEO

• ĐANG CÓ

• GIỚI HẠN

• ĐOÀN hoặc ĐOÀN TẤT CẢ

• Truy vấn con trong danh sách chọn

• Chỉ tham chiếu đến các giá trị bằng chữ (trong trường hợp này, không có bảng bên dưới)

[src]

Tôi sẽ mạo hiểm để đoán VIEWS của bạn đang yêu cầu thuật toán TEMPTABLE, gây ra các vấn đề về hiệu suất.

Đây là một bài đăng blog thực sự cũ về hiệu suất của các lượt xem trong MySQL và dường như nó đã không trở nên tốt hơn.

Tuy nhiên, có thể có một chút ánh sáng ở cuối đường hầm về vấn đề này của các bảng tạm thời không chứa các chỉ mục (gây ra quét toàn bộ bảng). Trong 5,6 :

Đối với các trường hợp khi yêu cầu vật chất hóa cho truy vấn con trong mệnh đề TỪ, trình tối ưu hóa có thể tăng tốc truy cập vào kết quả bằng cách thêm một chỉ mục vào bảng được cụ thể hóa. ... Sau khi thêm chỉ mục, trình tối ưu hóa có thể xử lý bảng dẫn xuất được vật chất hóa giống như một bảng thông thường với một chỉ mục và nó có lợi tương tự từ chỉ mục được tạo. Chi phí tạo ra chỉ mục không đáng kể so với chi phí thực hiện truy vấn mà không có chỉ mục.

Như @ypercube chỉ ra, MariaDB 5.3 đã thêm tối ưu hóa tương tự. Bài viết này có một cái nhìn tổng quan thú vị về quá trình:

Tối ưu hóa được áp dụng sau đó không thể hợp nhất bảng dẫn xuất vào bảng cha CHỌN của nó, điều này xảy ra khi bảng dẫn xuất không đáp ứng các tiêu chí để XEM

Lượt xem là công cụ bảo mật. Bạn không muốn một người dùng hoặc ứng dụng cụ thể biết bảng dữ liệu của bạn ở đâu, bạn cung cấp chế độ xem chỉ với các cột cần thiết.

Hãy nhớ rằng các khung nhìn luôn làm giảm hiệu suất, các truy vấn tương tự phải được lưu trữ các thủ tục và hàm, chứ không phải các khung nhìn.

Để thực hiện điều chỉnh truy vấn, luôn tuân theo các thực tiễn tốt nhất, tránh sử dụng các hàm trong mệnh đề WHERE, tạo các chỉ mục để tăng tốc độ chọn, nhưng không lạm dụng nó để lập chỉ mục chèn, cập nhật và xóa.

Có một tài liệu tốt có thể hỗ trợ bạn: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234

Tôi nghĩ rằng các khung nhìn là cấu trúc được xác định trước (không có dữ liệu) để hợp nhất các bảng thành một để khắc phục từ nhiều truy vấn bảng, có thể được sử dụng từ dữ liệu thực cho truy vấn quan hệ nhanh ...