Медленный запрос для таблицы 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 на выделенной виртуальной машине).

Solutions Collecting From Web of "Медленный запрос для таблицы wp_options"

Обновление : причина, по которой выполняется запрос, заключается в том, что он не использует индекс . Время запроса равно 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 Web Services (IP-адреса начинаются с 54. XXX и 32.XXX) пытались использовать /~web-root-dir/xmlrpc.php.

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

выберите * из wp_options, где option_name, например '% transient %';

Одним из полей, возвращаемых из этого запроса, является «option_value», который имеет тип данных LONGTEXT. Согласно документам mySQL, поле LONGTEXT (для каждой строки) может содержать до 4 гигабайт данных.

Когда я выполнил запрос, некоторые из строк (помните, работали с теми, которые содержат «переходные») имели огромное количество данных в поле option_value. Просматривая результаты, я также видел, что было похоже на попытки ввода команд в процесс wp-cron с надеждой на то, что они будут выполняться во время цикла (-ов).

Мое решение состояло в том, чтобы удалить все «переходные» строки. Это не повредит сервер, так как «переходные» строки будут автоматически заселяться (если они должны быть там).

После этого сервер снова был отзывчивым.

Запрос для удаления этих строк:

УДАЛИТЬ из wp_options, где option_name как '% transient %';

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