Медленный запрос для таблицы wp_options

Question

Медленный запрос для таблицы wp_options

6 нояб. 2012 г., 11:07:55

Просмотры: 39.3K

Голосов: 21

Я отслеживаю лог медленных запросов на сайте на базе WordPress (с установленным по умолчанию значением 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 и WordPress).

Prasad Ajinkya

482

производительность настройки

Комментарии

Голосую за закрытие этого вопроса, так как он был задан 8 лет назад. В последних обновлениях WordPress эта проблема была устранена.

Prasad Ajinkya

18 нояб. 2020 г. 14:15:31

Все ответы на вопрос

Комментарии

Сомневаюсь, что в этом случае индекс даст какое-либо преимущество — ознакомьтесь со статьёй о кардинальности.

TheDeadMedic

6 нояб. 2012 г. 16:50:39

Зависит от того, настроена ли автозагрузка для большинства опций. Думаю, что нет, но в любом случае таблица не должна становиться настолько большой, так что тут что-то нечисто.

Vinay Pai

6 нояб. 2012 г. 17:05:27

Я обновил свой ответ, добавив информацию о проверке распределения значений.

Vinay Pai

6 нояб. 2012 г. 17:14:01

Индекс не сократит конкретно время выполнения, но он предотвратит полное сканирование таблицы и связанные с этим блокировки.

Steve

6 нояб. 2012 г. 17:45:28

Я только что заметил комментарий и понял, что мой ответ полностью неверен. Запрос на самом деле не медленный... он просто попадает в лог медленных запросов, потому что не использует индекс.

Vinay Pai

6 нояб. 2012 г. 19:00:16

Показать остальные 4 комментариев

Несколько дней назад я обнаружил запрос в mytop, выполнявшийся на моем сервере, и каждый такой запрос занимал довольно много времени (около 10 секунд)! Это реальный пример ситуации, когда таблица wp_options может разрастись до проблемных размеров. В моем случае, я подозреваю, что плагин кэширования Cachify ответственен за раздувание wp_options.

Данные этой конкретной таблицы wp_options:

5 309 строк
130MB данных

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

Jan Papenbrock

161

27 мар. 2013 г. 20:19:42

В моей таблице wp_options было всего около 235 строк данных. Я пробовал индексировать таблицу, но это не помогло.

Оказалось, что около 150 временных (transient) опций было добавлено в таблицу, но они не были автоматически удалены.

Не знаю, связано ли это, но при просмотре файлов /var/log/apache2/access.log я заметил, что несколько (предположительно скомпрометированных) серверов Amazon Web Services (IP-адреса, начинающиеся с 54.X.X.X и 32.X.X.X) пытались эксплуатировать /~web-root-dir/xmlrpc.php.

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

select * from wp_options where option_name like '%_transient_%';

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

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

Моим решением было удалить все строки с "transient". Это не навредит серверу, так как временные строки автоматически восстановятся (если они действительно должны там быть).

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

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

DELETE from wp_options where option_name like '%_transient_%';

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

Ex_Military

31

7 сент. 2017 г. 04:55:15

Комментарии

Да. Я тоже мучился с "временем загрузки 40 секунд", пока не обнаружил, что у меня было 20 000 записей в wp_option с огромными данными, которые загружались при каждом открытии страницы. Удаление этих записей значительно ускорило сайт.

JasonGenX

12 февр. 2019 г. 19:34:29

Обновление, связанное с индексом для поля autoload в таблице wp_options:

Индекс для wp_options.autoload был добавлен в WordPress 5.3. Подробнее см. в Списке изменений WordPress 5.3

Вы также можете увидеть, что индексы доступны и для других столбцов в таблице wp_options:

SHOW INDEX from wp_options

Deepak Rajpal

264

19 авг. 2020 г. 10:47:36

Vinay Pai 296 · Accepted Answer · 2012-11-06T16:39:56Z

Обновление: Причина, по которой запрос логируется, заключается в том, что он не использует индекс. Время выполнения запроса равно 0, то есть он на самом деле выполняется быстро. Вы можете отключить опцию "log-queries-not-using-indexes", если не хотите, чтобы такие запросы логировались.

~~Таблица wp_options не имеет индекса на поле autoload~~ (теперь он должен быть, этот индекс был добавлен в схему ядра WordPress 15 августа 2019 года), поэтому запрос выполняет полное сканирование таблицы. Обычно эта таблица не должна становиться слишком большой, так что это не проблема, но, похоже, в вашем случае это произошло.

Добавление индекса может решить проблему, но, как отметил TheDeadMedic в комментариях, это может не помочь, если значения autoload преимущественно 'yes' или равномерно распределены между 'yes' и 'no':

Сначала выполните этот запрос, чтобы увидеть распределение:

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

Если подавляющее большинство значений равно 'no', вы можете временно решить проблему, добавив индекс на поле autoload.

ALTER TABLE wp_options ADD INDEX (`autoload`);

Однако вам стоит разобраться, почему таблица стала слишком большой. Возможно, это связано с плохо написанным плагином, который делает что-то подозрительное.