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

Что представляет собой таблица wp_options?

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

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

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

• option_id
• option_name
• option_value
• autoload

Важное поле, которое нас будет интересовать в таблице wp_options – это поле autoload. Оно содержит значение «yes» или «no» (флаг). В целом оно определяет, будет или нет та или иная опция загружаться в функцию wp_load_alloptions(). Автозагружаемые данные – это данные, которые загружаются на каждой странице вашего WordPress-сайта. Ситуация здесь такая же, как и со скриптами – далеко не всегда они должны загружаться на всех страницах сайта. Атрибут autoload по умолчанию ставится в «yes», однако теоретически далеко не каждому плагину требуется загружать свои данные на каждой странице.

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

• Данные автоматически загружаются плагином, когда в реальности их автозагрузка не требуется. Хороший пример: плагин контактной формы. Должен ли он загружать данные на каждой странице или только на контактной странице?
• Плагины или темы были удалены с 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';

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

Размер autoload_size вернется в байтах. В 1 Кб в данном случае будет 1000 байтов, а в 1 Мб – 1000 Кб. То есть, в нашем случае 249,025 байт – это 0.25 Мб. Для данного сайта это хороший размер. Если вам вернется размер, превышающий 1 Мб, вам нужно будет принять определенные меры.

Ниже представлен сайт, на котором было 137,724,715 байтов, т.е. 137 Мб автозагруженных данных. Яркий пример «плохого» сайта, который требует оптимизации.

Вы можете также использовать более длинные запросы, как в примере ниже. Они помогут вывести размер автозагруженных данных, число записей в таблице, а также первые 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)

Если у вас есть доступ к 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

Следующий шаг – рассмотрение отдельных автозагружаемых данных из полученного топ 10.

301_redirects

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

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

wpurp_custom_template_

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

grep -Ri "wpurp_custom_template_"

Команда выше, однако, ничего не дала, потому мы пошли в Google. Мы быстро обнаружили, что опция связана с WordPress плагином, который был удален с сайта. Плагин назывался WP Ultimate Recipe. Это классический пример ненужных данных, загружаемых автоматически даже после удаления самого плагина.

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, чтобы проверить наши папки с плагинами и темами.

grep -Ri "um_cache_userdata_"

Мы смогли установить, что строки относятся к плагину Ultimate Member. Быстрый поиск в Google помог найти несколько хороших решений этой проблемы. Оказывается, в плагине есть несколько способов справиться с данными последствиями:

• Ultimate Member > Dashboard > User Cache > Clear Cache.
• Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (ставим в ON), затем Save Changes.

Еще один хороший способ определить, к чему относится автозагружаемая опция – щелкнуть по кнопке Edit, после чего можно увидеть каталог плагинов/тем или ссылку на сайт разработчика.

Задачи Cron

Еще один источник проблем с большим объемом автозагружаемых данных – это опции, связанные с cron. Вы можете нажать Edit рядом с опцией, чтобы увидеть, что вызывает ее. Ниже представлен пример, из которого ясно, что do_pings был источником проблемы. Опять же, быстрый поиск в Google помог найти способ очистки do_pings.

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

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

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

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

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

Здесь мы видим строки от разных плагинов, которые уже не используются на сайте. К примеру, у нас есть строки плагина 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.

Очистка Transients (временных данных)

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

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

Лучше всего воспользоваться плагином, таким как Transient Cleaner, чтобы быстро удалить просроченные временные данные из wp_options.

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

Если очистка wp_options не дала результатов, вы можете попробовать добавить index к полю autoload. Это позволяет выполнять более эффективный поиск по автозагружаемым данным, что отражается на производительности сайта.

Little Bizzy создал плагин Index Autoload, который позволяет добавлять индекс к autoload в wp_options через WP-Cron на ежедневной основе.

Источник: kinsta.com