Ok, đây là truy vấn mà tôi đang chạy ngay trên bảng có 45.000 bản ghi và có kích thước 65MB ... và sắp trở nên lớn hơn và lớn hơn (vì vậy tôi phải suy nghĩ việc thực hiện trong tương lai cũng ở đây):Tối ưu hóa truy vấn SELECT được nhúng trong mySQL
SELECT count(payment_id) as signup_count, sum(amount) as signup_amount
FROM payments p
WHERE tm_completed BETWEEN '2009-05-01' AND '2009-05-30'
AND completed > 0
AND tm_completed IS NOT NULL
AND member_id NOT IN (SELECT p2.member_id FROM payments p2 WHERE p2.completed=1 AND p2.tm_completed < '2009-05-01' AND p2.tm_completed IS NOT NULL GROUP BY p2.member_id)
Và như bạn có thể hoặc có thể không tưởng tượng - nó nghẹn server mysql rơi vào bế tắc ...
những gì nó là - nó chỉ đơn giản kéo số của người dùng mới đã đăng ký, có ít nhất một khoản thanh toán "đã hoàn tất", tm_completed không trống (vì nó chỉ được điền cho các khoản thanh toán đã hoàn thành) và (Chọn được chọn) mà thành viên chưa bao giờ có "com pleted "thanh toán trước - nghĩa là anh ấy là thành viên mới (chỉ vì hệ thống thực hiện rebills và whatnot, và đây là cách duy nhất để phân biệt giữa thành viên hiện có vừa được trả lại và thành viên mới được lập hóa đơn lần đầu tiên) .
Bây giờ, có cách nào có thể để tối ưu hóa truy vấn này để sử dụng ít tài nguyên hơn hay gì đó, và ngừng sử dụng tài nguyên mysql trên đầu gối của họ ...?
Tôi có thiếu thông tin nào để làm rõ thêm điều này nữa không? Hãy cho tôi biết ...
EDIT:
Dưới đây là các chỉ số đã có trên bảng:
TIỂU TIỂU 46.757 payment_id
member_id INDEX 23.378 member_id
payer_id INDEX 11.689 payer_id
coupon_id INDEX 1 coupon_id
tm_added INDEX 46.757 tm_added, product_id
tm_completed INDEX 46.757 tm_completed, product_id
bạn có chỉ số trên các lĩnh vực nơi args tìm kiếm đang được sử dụng – James