Как удалить ненужные строки в базе данных WordPress

Удаление устаревших значений в базе данных WordPress

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

Очистка базы данных Вордпресс

Проблема состоит в том, что каждый раз при установке и активации нового плагина или темы в таблицу wp_postmeta базы данных WordPress записываются новые значения, а после их удаления многие из этих значений остаются мертвым грузом в базе. И чем старше блог, тем больше подобного «мусора» остается 😮

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

Но прежде, чем Вы начнете следовать моим инструкциям,  я настоятельно рекомендую сделать полную резервную копию БД. Для этого воспользуйтесь инструментом экспортирования в phpMyAdmin.

После того, как сделали бэкап, можно приступать. Войдите в phpMyAdmin, выберите базу данных, найдите таблицу wp_postmeta в  правой части панели управления и напротив нажмите на Структура:

База данных

Вы увидите такие варианты, как meta_id, post_id, meta_key и другие. Нас интересует meta_key — найдите строку с таким именем и нажмите на Обзор уникальных значений:

Таблица wp_postmeta

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

В моем примере я привел часть скриншота, на котором присутствуют следующие строки и их значения:

  • _aioseop_description — плагин All In One SEO Pack
  • _thumbnail_id — миниатюра поста (стандартное значение)
  • _wp_attached_file — прикрепленное изображение (стандартное значение)
  • _yarpp_body_keywords
  • _yarpp_related
  • _yarpp_title_keywords

Описания для последних трех строк я пропустил не случайно, а намеренно и даже выделил их на скриншоте ниже:

Строки meta_key

Дело в том, что эти строки отвечают за произвольные поля, вносимые плагином Yet Another Related Posts Plugin — вывод похожих записей. Действительно, очень давно я пользовался этим плагином, но вскоре удалил и заменил его простым кодом. Однако, как видите, порядка 2-3 лет эти строки хранились в базе данных.

Я буду использовать форму поиска, чтобы найти эти значения и удалить из базы данных WordPress. Не покидая текущую открытую страницу в панели phpMyAdmin нажмите на вкладку Поиск и затем напротив поля с названием meta_key в поле Значение напишите одно из найденных лишних значений. В моем примере это _yarpp_related. Затем нажимаем на кнопку OK:

Поиск по таблицам базы данных

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

Удаление устаревших значений

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

Стоит отметить, что существует специальный плагин под названием Clean Options. Он выполняет функции, похожие описанным в статье, но справляется не на все 100%, если взять те же значения, которые я использовал в качестве примера в статье — он их не находит и не удаляет. К тому же плагин давно не обновлялся (последняя версия вышла в  2010 году), не заявлена поддержка последних версий WP и самое главное — это небезопасно (может содержать уязвимости).

Рекомендую всем читателям как можно раньше провести ревизию своих блогов, выявить устаревшие плагины (не обновляемые более двух лет) и попытаться найти альтернативную замену.

В завершение предлагаю воспользоваться дополнительными средствами по очистке и оптимизации базы данных WordPress:

И напоследок, хочу обратить внимание, что в моем примере приведен стандартный префикс wp_ для таблиц, у Вас он может отличаться. Надеюсь, мне удалось все понятно объяснить, если появились вопросы — не стесняйтесь и смело задавайте в комментариях!

  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
(5 голосов, в среднем: 5 из 5)
Опубликовано 30.09.2014

Комментарии

  1. Галина Шевалер:

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

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

    Кстати, не предлагаете ли вы подобные услуги за деньги?

    Ответить

  2. Webliberty:

    Спасибо! Подобных платных услуг, к сожалению, не оказываю 😳

    Ответить

  3. Полезно! Денис, спасибо! Давно не чистил БД, скорее всего тоже висят старые данные в ней от плагинов, так как многое давно перевел на код. Надо на досуге заняться, поглядеть 😉

    Ответить

  4. Webliberty:

    Привет, Сергей! Я вот люблю все изучать, а тут как-то делал резервные копии и решил посмотреть проверить базы данных, мало ли следы взлома обнаружу… В последнее время больно много «левых» запросов идет к админке судя по логам, решил перестраховаться.

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

    Ответить

  5. Сергей:

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

    Ответить

  6. Webliberty:

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

    Ответить

  7. Артём:

    Вовремя нашёл ваш блог — тема как раз кстати. Уже начал ломать голову над тем, как избавиться от мусора. Спасибо автору за тщательную инструкцию. Помогла.

    Ответить

  8. Дмитрий:

    Привет Денис.
    Вы тут подняли тему в комментариях. А как проверить откуда идёт нагрузка на сервер. И вообще комплексные, действенные меры по снижению нагрузок на сервер, а то хостер грозится отключить сайт.

    И ещё вопрос: плагин удалил из админки, почистил базу, зашёл через файлзиллу и в папке с плагинами обнаружил остались файлы от плагинов типа: cforms-ru_RU.mo, wp-db-backup-ru_RU.po, и т.д. что за файлы (вроде бы файлы русификации)? я так понял эти остатки тоже надо удалять ручками?

    Ответить

  9. Webliberty:

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

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

    Ответить

  10. Remo:

    С автором полностью согласен — ПЕРЕД ТЕМ КАК ЧТО-ТО ДЕЛАТЬ С БАЗОЙ ДЕЛАЙТЕ БЕКАП! А так у WP есть один хороший плагин, который также чистит базу чуть ли не в режиме реального времени, называется — WP-Optimize. Посмотрите полезный плагин!

    Ответить

  11. Webliberty:

    WP-Optimize хороший плагин, подойдет нетривиальных задач, однако действия описанные в статье ни один плагин не выполнит. Так что плагин такой можно установить и польза будет непременно, но и ручками тоже приходится поработать)

    Ответить

  12. Геннадий Ольховский:

    Я тоже использую WP-Optimize, но Ваше решение проблемы удаления устаревших значений очень интересно, будем пробовать… 😉

    Ответить

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

    Вообще-то мне нужно сделать удаление большого куска кода на сайте. Это громадный файл шифрования нескольких плагинов. Обращалась на хостинг, говорят, что не нужно удалять. Что это нарушит корректную работу плагина bwp minyfy. Что-то не очень этому верю, потому что валидатор это фиксирует, как ошибку. Программа Xenus обозначает это ошибкой 404. Как это убрать пока не знаю. Может быть подскажете 😉

    Ответить

  14. Webliberty:

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

    Ответить

  15. Виталий:

    Здравствуйте, Webliberty!

    Огромное спасибо за нужную статью — прям в тему! 😎
    Вы правильно написали, что начинающие устанавливают кучу плагинов, а со временем их удаляют, как раз про меня) А «следы» плагинов и другой мусор накапливается 🙁

    Поэтому пришла очередь почистить БД, но в папке Плагины, что на сервере, обнаружил только установленные у меня плагины (лишних нет) и внимательно просмотрел найденные строки в meta_key никаких подозрительных значений (насколько я понимаю) не нашёл. Неужели удалённые плагины полностью удалились? Или может они ещё где-нибудь спрятались?

    Ещё вопрос, следов плагинов не нашёл, но нашёл значения _wp_old_slug, из название ясно, что это надо удалить, но вот вопросик: только эти значения? Как я понял все они идут «в связке» с другим значением, имеющим одинаковый номер, например: 469

    469 _yoast_wpseo_metakeywords интерьер трехкомнатной квартиры FORMA Design...
    469 wp_old_slug  interer-trehkomnatnoj-kvartiry-ot-forma-design

    Нужно удалять только значение _wp_old_slug или же вместе с вышеуказанным значением _yoast_wpseo_metakeywords?

    Ещё раз спасибо за толковые и профессиональные статьи и помощь,

    С уважением, Виталий

    Ответить

  16. Webliberty:

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

    Что касается _wp_old_slug, то здесь вручную лучше ничего не делать, слаги хранятся для всех записей, соответственно, чем больше записей, тем больше таких значений. Для удаления есть замечательный SQL запрос к БД, который автоматически их удалит в один клик.

    Ответить

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Отправляя комментарий, вы соглашаетесь с политикой конфиденциальности.