Как очистить orphaned postmeta в WordPress без риска для данных

Что такое orphaned postmeta и почему они появляются

Каждая строка в wp_postmeta содержит значение post_id, которое должно соответствовать ID записи в wp_posts. Если запись удалили, а связанные метаданные остались, появляются orphaned postmeta — метаданные без родительской записи.

Наиболее частые причины — массовое удаление контента, ошибки при импорте, некорректное удаление данных плагином, миграция сайта или ручные операции в базе данных. Иногда «сироты» остаются после удаления записей из корзины, если плагин или нестандартный скрипт не очистил связанные строки.

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

• Не путайте orphaned postmeta с метаданными записей в корзине, черновиков или записей с нестандартным post type: у них всё ещё есть строка в wp_posts.
• Не удаляйте метаданные только потому, что определённый meta_key кажется ненужным. Один и тот же ключ может использоваться разными плагинами или типами записей.

Подготовка к проверке и очистке

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

Перед выполнением DELETE создайте резервную копию базы данных. Лучше всего сохранить её в отдельный файл и убедиться, что файл создан и имеет ненулевой размер. Для критически важного сайта желательно также иметь проверенный способ восстановления.

На время очистки не запускайте импорт, массовое редактирование записей или процессы, которые могут одновременно изменять wp_posts и wp_postmeta.

• Проверьте подключение WP-CLI к нужной установке и базе данных.
• Зафиксируйте префикс таблиц и не копируйте запрос без его проверки.
• Выполняйте операцию в период низкой нагрузки.
• Сохраните результат проверки количества и примеры строк до очистки.

wp db export before-orphaned-postmeta.sql

wp db query "SHOW TABLES;"

Как посчитать orphaned postmeta

Для поиска используйте LEFT JOIN между wp_postmeta и wp_posts. Условие p.ID IS NULL оставляет только те метаданные, для которых не найдена соответствующая запись.

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

wp db query "
SELECT COUNT(*) AS orphaned_count
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
"

Просмотр примеров и распределение по meta_key

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

wp db query "
SELECT pm.meta_id, pm.post_id, pm.meta_key,
       LEFT(pm.meta_value, 200) AS meta_value_preview
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL
ORDER BY pm.meta_id
LIMIT 50;
"

wp db query "
SELECT pm.meta_key, COUNT(*) AS rows_count
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL
GROUP BY pm.meta_key
ORDER BY rows_count DESC;
"

Как безопасно удалить сиротские метаданные

Если проверка подтвердила, что найденные строки действительно не принадлежат ни одной записи, их можно удалить по тому же критерию. Запрос удаляет только строки из wp_postmeta, для которых в wp_posts нет соответствующего ID.

Не изменяйте условие на более широкий фильтр без чёткого понимания последствий. В частности, не следует удалять все строки с определённым meta_key или все метаданные старых записей только по дате.

• Перед выполнением ещё раз проверьте префикс таблиц.
• Убедитесь, что резервная копия создана до запуска DELETE.
• После операции проверьте количество orphaned postmeta повторным SELECT.
• Если строк очень много, сначала протестируйте операцию на копии базы данных или обсудите пакетное удаление с администратором базы.

wp db query "
DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
"

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

После DELETE повторите запрос COUNT. В штатной ситуации он должен вернуть ноль, если во время операции другой процесс не создал новые проблемные строки.

Также проверьте сайт в браузере: страницы записей, админ-панель, поиск, формы и функции, которые зависят от плагинов. Особенно внимательно протестируйте произвольные типы записей и поля, хранящиеся в postmeta.

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

wp db query "
SELECT COUNT(*) AS orphaned_count
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
"

Особенности Multisite и нестандартных баз данных

В WordPress Multisite каждый сайт имеет собственные таблицы записей и метаданных, например wp_2_posts и wp_2_postmeta. Проверять и очищать их нужно отдельно. Нельзя автоматически считать, что таблицы первого сайта содержат данные всех сайтов сети.

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

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

• Проверяйте каждый префикс отдельно.
• Не запускайте запрос с wp_ во всей сети, если не подтверждено, что это нужный сайт.
• После очистки проверьте журналы импорта и задания cron, которые могли стать причиной проблемы.

Распространённые ошибки при очистке

Самая опасная ошибка — выполнить DELETE без предварительного SELECT и резервной копии. Даже корректный на вид запрос может быть запущен не в той базе данных или с неправильным префиксом.

Другая проблема — попытка уменьшить размер базы удалением всех «старых» или «неизвестных» meta_key. Это может нарушить работу плагина, шаблона или произвольного типа записи.

Не следует считать оптимизацию таблицы заменой очистке. Сначала нужно определить и удалить только некорректные строки, а затем оценить необходимость оптимизации. Если orphaned-метаданные появляются снова, ищите плагин или процесс, который их создаёт.

• Не используйте запрос без проверки названия базы данных и таблиц.
• Не удаляйте строки только по meta_key.
• Не игнорируйте повторное появление проблемы после очистки.
• Не проводите операцию на рабочем сайте без актуальной резервной копии.