Как найти и убрать дубликаты мета-опций в WordPress

Дубли в wp_options обычно не бросаются в глаза, пока сайт не начинает медленнее открывать админку, странно вести себя после миграции или копить мусор от плагинов, которые сохраняют одни и те же настройки под разными ключами. Чаще всего проблема не в «битой базе» как таковой, а в том, что в таблице остаются старые опции после переезда, смены темы, тестов или неаккуратного удаления плагина.

Ниже разберём, как отличить безобидные повторы от реально лишних записей, как найти их через SQL и WP-CLI, и как удалить только то, что можно удалить без риска.

Когда дубли в wp_options действительно мешают

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

Типичные симптомы

• админка открывается заметно медленнее, особенно на сайтах с большим количеством автозагружаемых опций;
• после миграции настройки плагина не совпадают с тем, что видно в интерфейсе;
• в базе есть несколько похожих ключей с одинаковым префиксом, хотя плагин давно удалён;
• объём таблицы wp_options растёт без понятной причины;
• в autoload лежат старые значения, которые подгружаются на каждом запросе.

Диагностика проблемы: что искать в первую очередь

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

Проверка через SQL

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

SELECT option_name, LENGTH(option_value) AS size_bytes, autoload
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 50;

Дальше ищите группы с одинаковым префиксом. Например, если удалённый плагин оставил plugin_name_settings, plugin_name_cache, plugin_name_old, это уже повод проверить, используются ли они сейчас.

Чтобы увидеть похожие ключи по маске, можно использовать запрос с LIKE:

SELECT option_name, autoload
FROM wp_options
WHERE option_name LIKE 'plugin_name_%'
ORDER BY option_name;

Проверка через WP-CLI

Если WP-CLI доступен, он удобнее для быстрой ревизии. Сначала посмотрите все опции по маске:

wp option list --search=plugin_name_ --fields=option_name,autoload --format=table

Если ключей много, можно вывести только те, что автозагружаются:

wp option list --search=plugin_name_ --fields=option_name,autoload --format=table | grep yes

Это не идеальный фильтр, но для ручной проверки подходит. Главное — не удалять всё подряд по одному префиксу, пока не ясно, какие ключи реально используются активной версией плагина.

Пошаговое решение: как убрать лишние записи безопасно

Рабочая схема всегда одна: сначала резервная копия, потом список кандидатов на удаление, затем точечная чистка. Не наоборот.

Шаг 1. Сделайте бэкап таблицы

Если работаете через консоль, достаточно дампа одной таблицы:

wp db export wp_options-backup.sql --tables=wp_options

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

Шаг 2. Проверьте, не используется ли опция активным кодом

Перед удалением откройте поиск по теме и активным плагинам. Ищите вызовы get_option(), update_option(), add_option() и прямые обращения к нужному ключу. Если ключ встречается в коде активного плагина, удалять его нельзя.

Пример, что нужно искать:

get_option( 'plugin_name_settings' );
update_option( 'plugin_name_cache', $data );

Если код не найден, а плагин давно удалён, вероятность безопасной очистки выше.

Шаг 3. Удалите только конкретные ключи

Через WP-CLI удаление выглядит просто, но важно перечислить ключи вручную:

wp option delete plugin_name_old_cache
wp option delete plugin_name_legacy_settings

Если опций много, можно сначала выгрузить список в файл, проверить его глазами и только потом запускать удаление по списку. Для массовой очистки удобнее использовать SQL, но только после точной проверки имён:

DELETE FROM wp_options
WHERE option_name IN (
  'plugin_name_old_cache',
  'plugin_name_legacy_settings'
);

Если нужно убрать группу старых опций по префиксу, делайте это только после ручной сверки:

DELETE FROM wp_options
WHERE option_name LIKE 'plugin_name_old_%';

Такой запрос безопасен только тогда, когда вы уверены, что активный код не использует эти ключи.

Шаг 4. Очистите автозагрузку, если удалять пока рано

Иногда опцию ещё нельзя удалить, но она уже не должна грузиться на каждом запросе. Тогда можно временно отключить автозагрузку для неважных записей, если это действительно старый мусор. В MySQL это делается так:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'plugin_name_heavy_cache';

Это не замена удалению, но полезный промежуточный шаг, если вы хотите снизить нагрузку до полноценной чистки.

Сравнение подходов: плагин, SQL или WP-CLI

На практике для дубликатов мета-опций чаще всего выигрывает связка WP-CLI + ручная проверка. Плагин уместен, когда нужно быстро посмотреть объём мусора, но не когда речь идёт о точечном удалении ключей.

Проверка результата после очистки

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

Что проверить вручную

• открывается ли админка без ошибок;
• сохраняются ли настройки активных плагинов;
• не сбросилась ли тема на дефолтные значения;
• нет ли предупреждений в журнале ошибок PHP;
• не выросло ли число запросов к базе после очистки.

Что проверить через WP-CLI

Посмотрите, что ключ больше не существует:

wp option get plugin_name_old_cache

Если ключ удалён, команда вернёт ошибку о том, что опция не найдена. Затем проверьте оставшиеся связанные ключи:

wp option list --search=plugin_name_ --fields=option_name --format=table

Если вы чистили автозагрузку, можно дополнительно сверить, что тяжёлые старые записи больше не поднимаются на каждом запросе.

Частые ошибки и как их исправить

Удаляют по слишком широкому шаблону

Запрос вида DELETE FROM wp_options WHERE option_name LIKE 'plugin_%' опасен, если в проекте есть активные модули с тем же префиксом. Исправление простое: сначала список ключей, потом удаление только по IN (...) или по узкому шаблону после ручной проверки.

Путают дубли с сериализованными данными

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

Чистят без бэкапа

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

Удаляют опцию, которую читает активная тема

Такое часто бывает после смены темы: старая опция кажется ненужной, но в дочерней теме или кастомном плагине её ещё используют. Проверяйте поиск по коду не только в wp-content/themes, но и в собственных mu-плагинах.

Практические советы по безопасности и производительности

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

Если вам регулярно приходится чистить сайт от дублей, старых опций и следов удалённых плагинов, имеет смысл автоматизировать аудит. Для этого подходят штатные инструменты WordPress и WP-CLI, а для более широкой технической чистки — плагины уровня Clearfy Pro, если нужен именно набор для удаления дублей и мусора, а не точечный SQL.

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