Các truy vấn MySQL nhanh khi chạy trực tiếp nhưng thực sự chậm khi chạy dưới dạng proc được lưu trữ

Tôi đã từng gặp vấn đề tương tự. Sau một thời gian nghiên cứu, tôi phát hiện ra vấn đề là vấn đề đối chiếu trong khi MySQL đang so sánh văn bản.

TL; DR: bảng được tạo trong một lần đối chiếu trong khi MySQL "nghĩ" biến nằm trong một đối chiếu khác. Do đó, MySQL không thể sử dụng chỉ mục dành cho truy vấn.

Trong trường hợp của tôi, bảng được tạo bằng ( latin1 , latin1_swedish_ci ) đối chiếu. Để làm cho MySQL sử dụng chỉ mục, tôi phải thay đổi where mệnh đề trong thủ tục được lưu trữ từ

    UPDATE ... WHERE mycolumn = myvariable

đến

    UPDATE ... WHERE mycolumn = 
        convert(myvariable using latin1) collate latin1_swedish_ci

Sau khi thay đổi, thủ tục được lưu trữ trông giống như sau:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        UPDATE mytable SET mycolumn1 = variable1
        WHERE mycolumn2 = 
            convert(variable2 using latin1) collate latin1_swedish_ci
    END;

ở đâu ( latin1 , latin1_swedish_ci ) là đối chiếu giống với tableA của tôi được tạo bằng.

Để kiểm tra xem MySQL có sử dụng chỉ mục hay không, bạn có thể thay đổi quy trình được lưu trữ để chạy explain tuyên bố như sau:

    CREATE PROCEDURE foo.'bar'()
    BEGIN
        EXPLAIN SELECT * FROM table WHERE mycolumn2 = variable2
    END;

Trong trường hợp của tôi, explain kết quả cho thấy rằng không có chỉ mục nào được sử dụng trong quá trình thực thi truy vấn.

Lưu ý rằng MySQL có thể sử dụng chỉ mục khi bạn chạy truy vấn một mình, nhưng vẫn sẽ không sử dụng chỉ mục cho cùng một truy vấn bên trong một thủ tục được lưu trữ, điều này có thể do bằng cách nào đó MySQL thấy biến trong một đối chiếu khác.

Bạn có thể tìm thêm thông tin về vấn đề đối chiếu tại đây:http://lowleveldesign.wordpress.com/2013/07/19/diagnosing-collation-issue-mysql-stored-procedure/ Liên kết sao lưu: http ://www.codeproject.com/Articles/623272/Diagnosing-a-collation-issue-in-a-MySQL-stored-pro