Как очистить таблицу wp_options и данные автозагрузки

Updated 25 June 2022

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

Примечание. У меня на сайте есть большое руководство по Ускорению сайтов на WordPress.

Что такое таблица wp_options?

Таблица wp_options содержит всевозможные данные для вашего сайта WordPress, такие как:

  • URL сайта, домашний URL, email администратора, категория по умолчанию, посты на странице, формат времени и т.д.
  • Настройки для плагинов, тем, виджетов
  • Временно кэшированные данные

Таблица содержит следующие поля, одно из которых нас интересует больше, когда речь идет о производительности:

  • option_id (id опции)
  • option_name (имя опции)
  • option_value (значение опции)
  • autoload (автозагрузка)

Одной из важных вещей, которые необходимо понять о таблице wp_options, является поле autoload. Оно содержит значение (флаг) “да” (yes) или “нет” (no). По сути, оно контролирует, загружаются ли данные функцией wp_load_alloptions() (официальная документация).

Автозагружаемые данные – это данные, которые загружаются на каждой странице вашего сайта WordPress. Можно запретить определенным скриптам загружаться на весь сайт и здесь применима та же идея. Про плагины и скрипты мы поговорим в следующих постах.

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

Проблема, с которой могут столкнуться сайты WordPress, возникает, когда в таблице wp_options имеется большое количество данных автозагрузки. Обычно это является результатом следующего:

  • Данные автозагружаются плагином, хотя на самом деле для этого следует установить значение no (нет). Хорошим примером этого может быть плагин контактной формы. Нужно ли ему загружать данные на каждой странице или только на странице контактов?
  • Плагины или темы были удалены с сайта WordPress, но их параметры остались в таблице wp_options. Это может означать, что ненужные данные автозагрузки запрашиваются при каждом запросе.
  • Разработчики плагинов и тем загружают данные в таблицу wp_options вместо того, чтобы использовать собственные таблицы. На это есть аргументы с обеих сторон, так как некоторые разработчики предпочитают плагины, которые не создают дополнительных таблиц. Однако таблица wp_options также не была рассчитана на тысячи строк.

Какой объем данных является слишком большим для автозагрузки? Конечно, этот показатель может варьироваться, но в идеале он должен составлять от 300 КБ до 1 МБ. Как только вы начинаете приближаться к диапазону 3-5 МБ и более, скорее всего, есть вещи, которые можно оптимизировать или исключить из автозагрузки. А все, что превышает 10 МБ, должно быть рассмотрено немедленно. Это не всегда означает, что это вызовет проблему, но это хорошее начало.

Устранение проблем с автозагрузкой данных в таблице wp_options

Если на вашем сайте WordPress наблюдается медленная работа, это может быть связано с запросом к БД или автоматически загружаемыми данными, оставшимися от старых плагинов WordPress. Ниже я покажу вам, как проверить размер автозагрузки в вашей базе данных, мы погрузимся в данные действующего сайта и поделюсь тем, что я сделал, чтобы очистить таблицу.

Проверка размера данных автозагрузки

Первое, что нужно сделать, это проверить текущий размер автозагрузки на вашем сайте WordPress. Для этого войдите в phpMyAdmin. Выберите свою базу данных с левой стороны, перейдите на вкладку SQL. Затем введите следующую команду и нажмите Go:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Возможно, вам придется подкорректировать приведенный выше запрос, если ваш сайт WordPress использует другой префикс, отличный от wp_.

Размер autoload_size возвращается в байтах. В одном КБ содержится 1024 байта, а в одном МБ – 1024 КБ. Таким образом, в нашем случае 249 025 байт равны 0,25 МБ. Так что для данного сайта это хороший размер! Если вы получили результат меньше 1 МБ, вам не стоит беспокоиться. Однако если результат оказался намного больше, продолжайте изучение данной статьи.

Ниже представлен тестируемый сайт на котором было возвращено 137 724 715 байт, т.е. около 137 МБ. Это хороший пример сайта, где что-то определенно не так, и, конечно, есть что оптимизировать.

Большой объем автозагружаемых данных в таблице wp_options

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

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)

Пример того, что можем получить в случае этого запроса к Базе Данных:

Расширенный запрос MySQL с автозагрузкой данных

Если у вас есть доступ к New Relic (требуется лицензия), вы также можете использовать его для устранения неполадок в запросах, связанных с таблицей wp_options. Вкладка “Базы данных” укажет таблицу и тип запроса, потребляющего больше всего времени. Если выбрать одну из записей в списке, можно увидеть более подробную информацию, включая примеры запросов.

В примере ниже видно, что данные указывают на автозагрузку данных в таблице wp_options. Конечно, быстрый анализ рассматриваемого сайта подтвердил наличие почти 250 МБ автозагружаемых данных.

Сортировка основных данных автозагрузки

Следующим шагом будет быстрая сортировка основных элементов с автоматической загрузкой данных. Вот быстрая команда SQL, которую можно использовать для составления списка 10 лучших:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

Опять же, возможно, вам придется подкорректировать приведенный выше запрос, если ваш сайт WordPress использует другой префикс, отличный от wp_.

Исследование отдельных данных автозагрузки в wp_options

Следующим шагом будет изучение некоторых наиболее часто загружаемых автоматически данных, которые мы получили выше через запрос к БД.

301_redirects

Как мы можем видеть выше, самым первым и самым большим вариантом автозагрузки является 301_redirects. Вероятно, это напрямую связано с плагином перенаправления на сайте или плагином WordPress SEO, который также имеет функцию редиректа. В этом случае лучшей рекомендацией является реальная реализация редиректов на уровне сервера.

Почему? Потому что использование бесплатных плагинов WordPress для реализации редиректов иногда может вызвать проблемы с производительностью, так как большинство из них используют функцию wp_redirect, которая требует дополнительного выполнения кода и ресурсов. И, конечно, это также автозагрузка данных в таблице wp_options.

wpurp_custom_template_

Следующим по величине параметром автозагрузки данных был wpurp_custom_template_#. Мы видим, что для него существует довольно много различных строк. Обычно вы можете найти название этой опции и соединить точки, заглянув в папку тем или плагинов. В данном случае мы выполнили команду grep с сервера, чтобы проверить, сможем ли мы найти его. Вы также можете проверить его через SFTP.

grep -Ri "wpurp_custom_template_"

Однако вышеуказанная команда ничего не дала, поэтому пришлось залезть в Google и выполнить поиск. Быстро обнаружилось, что это было связано с плагином WordPress, который больше не был установлен на сайте, известным как WP Ultimate Recipe. Это классический пример ненужных данных, оставленных в автозагрузке. Скоро я опубликую подробное руководство по удалению плагинов WordPress правильным способом. Под правильным способом я подразумеваю реальную очистку оставленных данных.

um_cache_userdata_

Следующим по величине параметром автозагрузки данных был um_cache_userdata_#. Мы видим, что для этого параметра существует довольно много различных строк. Так как эта строка находилась в самом низу, мы быстро модифицировали нашу команду MySQL, чтобы показать 40 основных автозагружаемых данных:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;

Или суммируйте все значения с этим префиксом:

SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"

Мы увидели, что в таблице wp_options стало гораздо больше записей для um_cache_userdata_#. Мы снова запустили команду grep для проверки папок plugins и themes (плагинов и тем).

grep -Ri "um_cache_userdata_"

Затем мы смогли быстро определить, что это связано с плагином Ultimate Member. Еще один быстрый поиск в Google дал несколько хороших решений этой проблемы (см. статью). Никогда не стоит недооценивать силу поиска Google! Оказалось, что в плагине есть несколько различных вариантов решения этой проблемы:

  • Ultimate Member > Dashboard > User Cache > Clear Cache (Очистить кеш)
  • Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (переключить в ON), затем Save Changes

Другой способ посмотреть, что такое автозагрузка, – это нажать кнопку редактирования, где может быть указан каталог плагина/темы или сайт разработчика.

Cron Jobs

Еще один частый вариант, который мы видим при большом количестве автозагружаемых данных, – это cron. Это может быть что угодно, связанное с cron (крон).

Справка. cron — классический демон (компьютерная программа в системах класса UNIX), использующийся для периодического выполнения заданий в определённое время.

Поэтому вы можете нажать кнопку “редактировать”, чтобы увидеть причину. Вот пример ниже, в котором было очевидно, что причиной проблемы является “do_pings”. Опять же, быстрый поиск в Google выявил быстрое решение для очистки do_pings.

Очистка таблицы wp_options

Если вы часто видите то, о чем мы говорили выше, то, вероятно, пришло время очистить все данные автозагрузки в таблице wp_options. Также рекомендуется постараться свести количество строк в таблице wp_options к минимуму. Пожалуйста, всегда делайте резервные копии перед удалением данных в вашей базе данных. Если вам неудобно делать это самостоятельно, мы всегда рекомендуем нанять разработчика WordPress.

Как мы делали ранее, вам нужно войти в phpMyAdmin. Нажмите на свою базу данных с левой стороны, а затем на вкладку SQL. Затем введите следующую команду и нажмите Go:

SELECT * FROM `wp_options` WHERE `autoload` = 'yes'

Возможно, вам придется подкорректировать приведенный выше запрос, если ваш сайт WordPress использует другой префикс, отличный от wp_. Это покажет вам все данные в таблице wp_options, которые настроены на автозагрузку.

Прокручивая вниз строки, мы видим всевозможные плагины, которые больше не установлены или не используются сайтом. Это всего лишь пример, который мы будем использовать, но в данном случае мы заметили кучу строк Jetpack. Но Jetpack больше не использовался на данном сайте.

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

Итак, в данном случае мы выполним следующий запрос, чтобы найти автозагруженные данные в таблице wp_options от плагина Jetpack. Чтобы изменить запрос на свой собственный, просто замените %jetpack%.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'

Затем вы можете выделить все строки и нажать Delete (Удалить).

Или вы можете выполнить следующую команду:

DELETE
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'

В итоге мы увидим следующую картину:

Удаление автозагружаемых данных в таблице wp_options

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

Очистка Transients

Transients или временные данные – это способ кэширования данных на определенное время в WordPress. В отличие от хранения данных в кэше объектов, временные данные (или переходные) хранятся только временно, с расчетом на то, что они будут периодически обновляться. Переходные данные всегда создаются с заданным максимальным временем жизни, после чего оно истекают и данные удаляются.

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

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Однако лучшим и более безопасным вариантом будет использование бесплатного плагина Transient Cleaner, который может очистить только просроченные (expired) временные данные из таблицы wp_options.

Очистка сеансов (сессий) WordPress

Другая распространенная проблема, с которой мы сталкиваемся, заключается в том, что иногда задания cron рассинхронизируются или не срабатывают должным образом, и поэтому сессии не очищаются. В результате вы можете получить тонны строк _wp_session_ в вашей базе данных. В приведенном ниже примере сайт, о котором идет речь, имел более 3 миллионов строк в таблице wp_options. Размер таблицы превышал 600 МБ.

Вы можете использовать запрос, подобный приведенному ниже, чтобы проверить, сталкиваетесь ли вы с этой проблемой:

SELECT * 
FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

Результат запроса:

Строки _wp_session_

В большинстве случаев их можно безопасно удалить (как и должно быть в задании cron) с помощью следующей команды:

DELETE FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

После очистки всех оставшихся строк _wp_session_ таблица содержала менее 1 000 строк и была уменьшена до 11 МБ.

Он также исправил пики нагрузки, которые сайт получал в MySQL.

Добавление индекса в автозагрузку

А если очистки таблицы wp_options недостаточно, можно попробовать добавить “индекс” (Index) к полю автозагрузки. Это, по сути, может помочь более эффективному поиску.

Замечательная команда из 10up провела несколько тестовых сценариев на таблице wp_options с типичным количеством записей в автозагрузке, чтобы показать, как добавление индекса автозагрузки к запросам wp_options может повысить производительность.

Время запроса wp_options (C) Картинка 10up

Мы коснулись основных моментов по оптимизации wp_options и Базы Данных WordPress. В следующих статьях будет больше всего интересного по этой теме.

Published 25 May 2022
Category: Блог
Tags: ,

Leave a Reply

Your email address will not be published.