Theo các hạn chế về thói quen và trình kích hoạt được lưu trữ , sql động không thể được sử dụng (hạn chế được gỡ bỏ đối với các thủ tục được lưu trữ trong phiên bản 5.0.13 trở lên). Tại sao giới hạn này được đặt ra? Và tại sao nâng nó cho các thủ tục, nhưng không phải chức năng hoặc kích hoạt?
Câu trả lời:
Chỉ cần nghe câu hỏi thôi cũng khiến tôi nghĩ đến hai khía cạnh:
NHIỆM VỤ # 1: Các chức năng được cho là XÁC ĐỊNH
Nếu đúng như vậy, điều này ngụ ý rằng một hàm sẽ hiển thị cùng một dữ liệu trả về cho một tập hợp các tham số nhất định, KHÔNG CÓ VẤN ĐỀ KHI BẠN GỌI CHỨC NĂNG.
Bây giờ, hãy tưởng tượng một hàm tạo ra một câu trả lời khác nhau vì thu thập dữ liệu vào các thời điểm khác nhau trong ngày dựa trên SQL tĩnh trong hàm. Theo một nghĩa nào đó, điều đó vẫn có thể được coi là DETERMINISTIC nếu bạn truy vấn cùng một tập hợp các bảng và cột mỗi lần, với cùng một bộ tham số.
Điều gì xảy ra nếu bạn có thể thay đổi các bảng cơ bản của hàm thông qua SQL động? Bạn đang vi phạm định nghĩa của hàm DETERMINISTIC.
Lưu ý rằng MySQL đã thêm tùy chọn này trong /etc/my.cnf
log-bin-trust-function-creatorsMặc dù điều này có thể là một sự đơn giản hóa để nói, điều này cho phép các chức năng được phép ghi dữ liệu vào nhật ký nhị phân mà không thực thi nghiêm ngặt thuộc tính DETERMINISTIC.
NHIỆM VỤ # 2: Kích hoạt sẽ có thể được khôi phục
Về cơ bản, bạn sẽ có dữ liệu tăng trưởng bậc hai (thậm chí theo cấp số nhân) chỉ trong MVCC. Quá trình quản lý rollback của SQL với các trình kích hoạt có thể không phải là DETERMINISTIC sẽ rất phức tạp, phải nói là ít nhất.
Xét về hai khía cạnh này, tôi chắc chắn các Nhà phát triển MySQL đã nghĩ đến những điều này và nhanh chóng loại bỏ chúng bằng cách áp đặt các hạn chế.
Vì vậy, tại sao nâng hạn chế cho Thủ tục? Nói một cách đơn giản, không có mối quan tâm nào về các thuộc tính DETERMINISTIC hoặc Rollback.
Đây là một câu hỏi hay, nhưng tôi không biết câu trả lời. Tôi tưởng tượng điều này sẽ phải đi theo nhóm nội bộ, nhưng tôi không biết rằng họ sẽ tham gia vào trang web này. Trong khi đó, tôi có thể giúp bạn suy luận một số câu trả lời.
Để bắt đầu, tôi thấy điều này:
Bộ đệm kích hoạt không phát hiện khi siêu dữ liệu của các đối tượng cơ bản đã thay đổi. Nếu một kích hoạt sử dụng một bảng và bảng đã thay đổi kể từ khi kích hoạt được tải vào bộ đệm, kích hoạt hoạt động bằng cách sử dụng siêu dữ liệu lỗi thời.
Điều đó khiến tôi nghĩ rằng điều đó có liên quan đến nó. Nó sẽ không được biên dịch lại SQL nếu nó thậm chí không theo dõi siêu dữ liệu. Điều đó có nghĩa là nó là một mối quan tâm động cơ.
Với cùng một mã thông báo, khi tôi đọc khối này, tôi nghĩ điều tương tự (động cơ):
Để ngăn chặn sự cố tương tác giữa các luồng máy chủ, khi máy khách đưa ra câu lệnh, máy chủ sử dụng ảnh chụp nhanh các thói quen và kích hoạt có sẵn để thực hiện câu lệnh. Nghĩa là, máy chủ tính toán một danh sách các thủ tục, hàm và các kích hoạt có thể được sử dụng trong quá trình thực thi câu lệnh, tải chúng và sau đó tiến hành thực hiện câu lệnh. Điều này có nghĩa là trong khi câu lệnh thực thi, nó sẽ không thấy các thay đổi đối với các thường trình được thực hiện bởi các luồng khác.
Vì vậy, tất cả trong tất cả tôi không hoàn toàn chắc chắn tại sao họ không cho phép nó, nhưng tôi có thể đoán. Xin lỗi vì tôi không thể giúp bạn nhiều hơn, tôi sẵn sàng nói thêm điều này. Tốt nhất là hy vọng vào một số nhà phát triển MySQL đang hoạt động khi chúng tôi rời khỏi phiên bản beta riêng tư;)
Phần lớn, đó là do an ninh. Ngoại lệ cho các thủ tục là vì SQL động trong thủ tục có thể được chỉ định bối cảnh bảo mật của người dùng thực thi. Điều này có nghĩa là mặc dù động cơ không biết điều gì sẽ được thực thi, nhưng nó có thể chắc chắn rằng người dùng được phép truy cập (các) đối tượng được tham chiếu.
Ngoài ra, bạn có thể nêu ra những vấn đề xấu xí về những gì có thể xảy ra, liệu nó có được phép hay không.