Повільний запит для таблиці wp_options

Я відстежував журнал повільних запитів веб-сайту на базі WP (значення за замовчуванням long_query_time встановлено на 10), і я помітив, що наступний запит часто отримує реєстрацію -

# 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';

Я не розумію, як така маленька таблиця може зайняти стільки часу для виконання. Це просто симптом якоїсь іншої проблеми? (На даний момент працює Moodle, phpbb та WP на спеціальному VM).

Оновлення . Причина запису запису полягає в тому, що він не використовує індекс . Час запиту дорівнює 0, тобто він фактично виконується швидко. Ви можете скасувати параметр "log-queries-not-using-indexes", якщо ви не хочете, щоб вони реєструвалися.

У таблиці wp_options немає індексу автоматичного завантаження, тому запит закінчується скануванням повної таблиці. Взагалі, таблиця не повинна бути надто великою, тому це не проблема, але я гадаю, що у вашому випадку це якось трапилося.

Додавання індексу може вирішити проблему, але, як TheDeadMedic зазначав у коментарях, це може не статися, якщо значення автозавантаження є більшістю так, або рівномірно розподіленими між так і ні:

Спочатку зробіть цей запит, щоб побачити, як виглядає дистрибутив:

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

якщо для більшості з них встановлено значення "ні", ви можете вирішити проблему, додавши індекс на автоматичне завантаження.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Однак, можливо, ви захочете дійти до нижньої частини, чому ця таблиця стала занадто великою. Можливо, якийсь погано написаний плагін робить щось рибне.

Я наткнувся на запит, згаданий у mytop, що працює на моєму сервері кілька днів тому - і це фактично зайняло досить багато часу (приблизно 10 секунд) на кожен запит! Тож існують ситуації в реальному світі, коли wp_options можуть вирости до проблемних розмірів. У моєму випадку я підозрюю, що плагін кешування Cachify несе відповідальність за здуття wp_options.

Дані саме цього wp_options:

5,309 rows
130MB of data

В якості рішення я додав індекс, подібний до рішення, опублікованого Vinay Pai, який вирішив проблему бездоганно.

Моя таблиця wp_options містила лише близько 235 рядків даних. Я спробував індексувати таблицю, але це не допомогло.

Виявляється, у таблицю було вставлено близько 150 перехідних варіантів, але їх не було автоматично видалено.

Я не знаю, пов'язано це чи ні, але я переглянув файли /var/log/apache2/access.log і помітив, що декілька (імовірно компрометовані) сервери веб-служб Amazon (IP-адреси, починаючи з 54. XXX та 32.XXX) намагалися використовувати /~web-root-dir/xmlrpc.php.

Після деякого усунення несправностей я запитав таблицю wp_options для імен параметрів, що містили "перехідний"

виберіть * з wp_options, де параметр_імен типу "% перехідний %";

Одним із полів, повернутих із цього запиту, є 'option_value', який має тип даних LONGTEXT. Згідно з документами mySQL, поле LONGTEXT (для кожного ряду) може містити до 4-гігабайтних даних.

Коли я виконував запит, деякі рядки (пам'ятаю, працювали з тими, що містять "перехідні") мали масив обсяги даних у полі option_value. Переглядаючи результати, я також побачив, як виглядали спроби ввести команди в процес wp-cron з надією, що вони будуть виконані під час циклу (ів) кронів.

Моє рішення полягало в тому, щоб видалити всі "минущі" рядки. Це не зашкодить серверу, оскільки "перехідні" рядки автоматично переселяться (якщо вони повинні бути там).

Після цього сервер знову реагував.

Запит на видалення цих рядків:

УВІДКЛЮЧАТИ з wp_options, де назва_меню на зразок '% перехідний %';

Я також додав IP-адресу AWS / 8 суперблоків до свого брандмауера (-::