MySQL (giống như hầu hết DBMS) sẽ lưu trữ các kế hoạch thực thi cho các câu lệnh đã chuẩn bị sẵn, vì vậy nếu người dùng A tạo một kế hoạch cho:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(trong đó v1 và v2 là các liên kết vars) sau đó gửi các giá trị để được nội suy bởi DBMS, sau đó người dùng B gửi cùng một truy vấn (nhưng với các giá trị khác nhau để nội suy) DBMS không phải tạo lại kế hoạch. tức là đó là DBMS tìm ra kế hoạch phù hợp - không phải PDO.
Tuy nhiên, điều này có nghĩa là mỗi thao tác trên cơ sở dữ liệu yêu cầu ít nhất 2 chuyến khứ hồi (lần thứ nhất để trình bày truy vấn, lần thứ hai để trình bày các liên kết) trái ngược với một chuyến khứ hồi cho một truy vấn có giá trị theo nghĩa đen, sau đó điều này dẫn đến chi phí mạng bổ sung . Ngoài ra còn có một khoản chi phí nhỏ liên quan đến việc tham khảo (và duy trì) bộ đệm truy vấn / kế hoạch.
Câu hỏi quan trọng là liệu chi phí này có lớn hơn chi phí tạo ra kế hoạch ngay từ đầu hay không.
Mặc dù (theo kinh nghiệm của tôi) chắc chắn có lợi ích về hiệu suất khi sử dụng các câu lệnh đã chuẩn bị sẵn với Oracle, nhưng tôi không tin rằng điều này cũng đúng với MySQL - tuy nhiên, phần lớn sẽ phụ thuộc vào cấu trúc cơ sở dữ liệu của bạn và độ phức tạp của truy vấn (hoặc cụ thể hơn, có bao nhiêu tùy chọn khác nhau mà trình tối ưu hóa có thể tìm thấy để giải quyết truy vấn).
Hãy thử tự đo lường nó (gợi ý:bạn có thể muốn đặt ngưỡng truy vấn chậm thành 0 và viết một số mã để chuyển đổi các giá trị theo nghĩa đen trở lại thành biểu diễn ẩn danh cho các truy vấn được ghi vào nhật ký).
