Truy vấn chậm cho bảng wp_options

Tôi đã theo dõi nhật ký truy vấn chậm của trang web dựa trên WP (với giá trị mặc định của long_query_time được đặt thành 10) và tôi nhận thấy rằng truy vấn sau thường được ghi lại -

# User@Host: root[root] @ localhost []
# Query_time: 0  Lock_time: 0  Rows_sent: 394  Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Tôi không hiểu làm thế nào một cái bàn nhỏ như vậy có thể mất nhiều thời gian để thực hiện. Đây có phải chỉ là một triệu chứng của một số vấn đề khác? (Hiện đang chạy Moodle, phpbb và WP trên máy ảo chuyên dụng).

Cập nhật : Lý do truy vấn đang được ghi là nó không sử dụng một chỉ mục . Thời gian truy vấn là 0, tức là nó thực sự thực thi nhanh. Bạn có thể bỏ đặt tùy chọn "log-query-not-used-indexes" nếu bạn không muốn chúng được ghi lại.

Bảng wp_options không có chỉ mục trên tự động tải, do đó, truy vấn kết thúc khi thực hiện quét toàn bộ bảng. Nói chung, bảng không nên quá lớn, vì vậy nó không phải là vấn đề, nhưng tôi đoán điều đó đã xảy ra trong trường hợp của bạn.

Việc thêm một chỉ mục có thể giải quyết vấn đề, nhưng như TheDeadMedic đã chỉ ra trong các bình luận, có thể không nếu các giá trị của tự động tải là đa số có hoặc phân bổ đều giữa có và không:

Đầu tiên, thực hiện truy vấn này để xem phân phối trông như thế nào:

SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;

nếu phần lớn trong số chúng được đặt thành 'không', bạn có thể giải quyết vấn đề ngay bây giờ bằng cách thêm chỉ mục vào tự động tải.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Tuy nhiên, bạn có thể muốn đi đến tận cùng lý do tại sao bảng đó đã trở nên quá lớn. Có thể một số plugin viết xấu làm một cái gì đó tanh.

Tôi tình cờ thấy truy vấn được đề cập trong mytop chạy trên máy chủ của tôi vài ngày trước - và nó thực sự mất khá nhiều thời gian (khoảng 10 giây) cho mỗi truy vấn! Vì vậy, có những tình huống trong thế giới thực, nơi wp_options có thể phát triển đến kích thước có vấn đề. Trong trường hợp của tôi, tôi nghi ngờ plugin bộ nhớ đệm Cache là chịu trách nhiệm cho việc làm đầy wp_options.

Dữ liệu của wp_options cụ thể này:

5,309 rows
130MB of data

Như một giải pháp, tôi đã thêm chỉ số tương tự như giải pháp được đăng bởi Vinay Pai, giải quyết vấn đề hoàn hảo.

Bảng wp_options của tôi chỉ có khoảng 235 hàng dữ liệu. Tôi đã thử lập chỉ mục bảng, nhưng nó không giúp được gì.

Hóa ra khoảng 150 tùy chọn thoáng qua đã được chèn vào bảng, nhưng chưa được xóa tự động.

Tôi không biết nó có liên quan hay không, nhưng tôi đã xem qua các tệp /var/log/apache2/access.log của tôi và nhận thấy rằng nhiều máy chủ Amazon Web Services (có thể bị xâm phạm) (địa chỉ IP bắt đầu bằng 54. XXX và 32.XXX) đã cố gắng khai thác /~web-root-dir/xmlrpc.php.

Sau một số khắc phục sự cố, tôi đã truy vấn bảng wp_options cho các tên tùy chọn có chứa "tạm thời"

chọn * từ wp_options trong đó tùy chọn_name như '% thoáng qua %';

Một trong các trường được trả về từ truy vấn này là 'tùy chọn_value' có kiểu dữ liệu là LONGTEXT. Theo các tài liệu myQuery, một trường LONGTEXT (cho mỗi hàng) có thể chứa tới 4 Gigabyte dữ liệu.

Khi tôi thực hiện truy vấn, một số hàng (nhớ đang hoạt động với những hàng có chứa "tạm thời") có lượng dữ liệu khổng lồ trong trường tùy chọn_value. Nhìn qua các kết quả, tôi cũng thấy những gì trông giống như cố gắng đưa lệnh vào quy trình wp-cron với hy vọng chúng sẽ được thực thi trong (các) chu kỳ cron.

Giải pháp của tôi là xóa tất cả các hàng "thoáng qua". Điều này sẽ không gây hại cho máy chủ vì các hàng "thoáng qua" sẽ tự động phục hồi (nếu chúng được cho là ở đó).

Sau khi làm điều này, máy chủ một lần nữa đáp ứng.

Truy vấn để xóa các hàng này:

XÓA từ wp_options trong đó tùy chọn_name như '% thoáng qua %';

Tôi cũng đã thêm địa chỉ IP AWS / 8 siêu khóa vào tường lửa của mình (-: