2012-04-30 40 views
5

làm trạng thái tiêu đề, trong cơ sở dữ liệu truy vấn khác nhau của tôi xuất hiện trong nhật ký truy vấn chậm, nhưng khi tôi chạy chúng theo cách thủ công, chúng chạy nhanh hơn 10x.Truy vấn chậm MYSQL trong "truy vấn chậm đăng nhập" - nhưng cùng một truy vấn chạy rất nhanh theo cách thủ công

ví dụ truy vấn chọn tương đối đơn giản với nhiều thứ tự theo tham số thường mất tối đa 100 giây trong nhật ký (có bảng rất lớn) ... nhưng khi tôi tự chạy nó trên cùng một DB thì phải mất 2 giây hoặc lâu hơn .

Tôi đã kiểm tra hiệu suất của máy chủ và dường như không có sự sụt giảm hoặc nút cổ chai cụ thể vào thời điểm đó, cũng như không có nhiều truy vấn mất nhiều thời gian vào thời điểm đó mà chỉ là thời gian.

làm cách nào để tôi có thể bắt đầu phân tích vấn đề như vậy?

cảm ơn sự giúp đỡ

+0

Tôi bắt đầu bằng cách đăng một trong các truy vấn như vậy ở đây để được trợ giúp phân tích nó cùng với "GIẢI THÍCH CHỌN ..." để cho biết công cụ muốn làm gì cho đường dẫn truy vấn của nó. – DRapp

+0

Thông thường nếu một truy vấn mất 1 hoặc nhiều giây được truy vấn bởi nhật ký truy vấn chậm. 2 giây chắc chắn là cao hơn 1 giây. –

+0

Đoán ngẫu nhiên: Truy vấn nhanh khi bạn chạy thủ công vì kết quả được lưu trong bộ nhớ cache trong lần thực hiện truy vấn đầu tiên. Để kiểm tra, hãy xóa tất cả bộ nhớ cache và sau đó thử lại cùng một truy vấn - sẽ mất 100 giây. – nikhil500

Trả lời

5

Hệ thống của bạn có thể bận rộn hơn khi truy vấn vi phạm nhập nhật ký chậm.

Nhật ký chậm có thể chỉ ra rằng các chỉ mục không được sử dụng đầy đủ nếu rows_examined lớn hơn tập hợp kết quả. Do đó, thời gian thực hiện nên được coi là một đầu mối cho thấy một truy vấn có vấn đề, nhưng rows_examined sẽ cung cấp cho bạn nhiều câu trả lời dứt khoát hơn.

Thời gian truy vấn là đo lường hiệu suất kém trên máy chủ có tải cao vì mọi truy vấn có thể chậm trên máy chủ bận. Bạn nên sử dụng EXPLAIN và SHOW PROFILE để cấu hình các truy vấn của bạn và cải thiện chúng để chúng không tải quá nhiều vào máy chủ của bạn.

Sử dụng SELECT SQL_NO_CACHE ... khi định cấu hình truy vấn để kết quả không được lưu trữ trong bộ đệm truy vấn, nếu không thì truy vấn tương tự có thể sử dụng bộ nhớ truy vấn, xoay bất kỳ thời điểm truy vấn nào.

+0

liên quan đến bộ nhớ cache: khi tôi chạy truy vấn theo cách thủ công (vẫn còn trên máy chủ, không cục bộ, trên cùng một DB), tôi đã thay đổi thứ tự của một số điều kiện, do đó, nó sẽ không thể khớp kết quả với truy vấn được chạy trước đó. Tôi đã chạy giải thích và nó cho thấy nó sử dụng một số chỉ mục, nhưng tôi thực sự không chắc chắn nếu chúng là chính xác. trong danh sách "chỉ mục có thể", có nhiều chỉ mục khác không được sử dụng. –

+0

Tôi cũng nhận thấy rằng số lượng hàng được quét vượt quá số hàng thực sự được tìm nạp. trong thực tế, bản thân tuyên bố có LIMIT 50 trên nó, và các hàng quét được khoảng 3000. suy nghĩ của tôi là do ORDER BY trong câu lệnh, mà hiểu biết của tôi tìm nạp tất cả các hàng (mặc dù có LIMIT trên truy vấn) và chỉ sau khi đơn đặt hàng của nó trả về 50. điều này có đúng không? –

+0

@MikiBergin, Nếu mệnh đề ORDER BY có thể được phân phối bởi chỉ mục, thì nó sẽ không nhất thiết phải lấy tất cả các hàng. Có một số cảnh báo, nhưng đó là quá nhiều để thảo luận ở đây. Tôi khuyên bạn nên nếu bạn cần trợ giúp tối ưu hóa một truy vấn cụ thể, vui lòng đăng câu hỏi riêng, hoàn thành với toàn bộ truy vấn, lược đồ có liên quan và kết quả GIẢI THÍCH và HIỂN THỊ HỒ SƠ. –

Các vấn đề liên quan