Удаление лишних meta-ключей WordPress SQL запросом

Здравствуйте! Когда-то я уже затрагивал тему очистки базы данных от старых таблиц и строк, которые уже потеряли актуальность. И речь тогда шла про «мусор», оставляемый различными плагинами после их удаления.

База данных MySQL

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

Наверняка Вам не раз приходилось пересохранять и публиковать посты заново, допустим после прочтения опубликованного материала нашли грамматическую ошибку или просто решили подправить… Да все что угодно! Я не раз и не два иногда обновляю свои записи.

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

И каждый раз Вордпресс записывает в базу данных дату и время последнего редактирования записи, старые адреса ссылок и прочую ненужную информацию — все это несомненно загромождает базу данных и замедляет работу. Чтобы навести порядок во всем этом не потребуется особых знаний и умений, достаточно всего лишь выполнить SQL запрос к базе данных WordPress в панели PhpMyAdmin.

SQL запрос

SQL запрос к базе данных WordPress

Сделали бэкап базы данных? Отлично! Тогда можно приступать! Необходимо выполнить следующий запрос к базе данных:

DELETE FROM `wp_postmeta`
WHERE `meta_key` IN('_edit_lock', '_edit_last','_wp_old_slug')

Выполняя данный запрос мы удаляем из таблицы wp_postmeta следующие ключи:

  1. _edit_lock Оказывается, если для пользователей открыт доступ для написания постов на Вашем блоге, т.е. в консоли управления на вкладке «Параметры» в пункте «Общие» роль нового пользователя будет обозначена как Автор, то данный параметр будет отвечать за время в течение которого он может изменять свое сообщение в течение указанного срока. В базе данных значение может выглядеть так: edit_lock = 60
    В данном примере число 60 говорит о том, что у пользователя есть 60 минут на редактирование своего сообщения с момента публикации. Данный параметр считаю абсолютно бесполезным в том случае, если владелец сайта является единственным автором статей.
  2. _edit_last Данный параметр содержит информацию о времени последнего редактирования записи. Не несет в себе смысловой нагрузки и его также можно удалять.
  3. _wp_old_slug А здесь уже интереснее 😉 Параметр содержит информацию о предыдущем адресе поста, если были изменения. Хочу привести пример на своем опыте. Когда я создавал самую первую запись на своем блоге, то это была не новая запись, а редактировался пост по-умолчанию, созданный вордпрессом с название «Привет мир!» и ссылка имела вид: https://webliberty.ru/privet-mir/

    Да, именно так она и выглядела, т.к. ЧПУ я настроил сразу же. Со временем, подумав, что на каждом втором блоге буде ссылка с таким же адресом я решил ее изменить и сделал так: https://webliberty.ru/moy-pervyiy-post/

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

    Так вот, из моего примера Вы уже поняли, что WordPress хранит в базе данных старые адреса страниц и при их смене производит редирект на новый адрес. Сервер отдает такую страницу с заголовком 200(OK) 🙁 хотя по идее должен отдавать 404 (страница не найдена). После выполнения данного запроса к базе старые адреса с успехом удалились, редиректа не происходит и google наконец то выкинул несуществующую страницу из поиска, т.к. сервер отдает ее с ошибкой 404.

Результаты выполнения запроса

После выполнения SQL запросов в моей базе данных было удалено 34 строки, сократив ее размер. А борьба с гуглом по поводу несуществующих страниц и редиректа была завершена.

Удаление значений в базе данных

Вот такую небольшую чистку базы данных WordPress я устроил путем удаления ненужных meta-ключей с помощью SQL-запроса, она ее выдержала и чувствует себя замечательно, как видите все функционирует.

  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
(5 голосов, в среднем: 5 из 5)
  1. Ahawks

    Очень полезная статья, попробую сегодня завтра этот метод, а то очень часто изменяю то или другое на блогах. Спасибо за материал.

    Ответить

  2. Webliberty

    Ahawks, базу данных можно назвать «сердцем» блога, это та составляющая, без которой не обойтись, поэтому следует содержать ее в чистоте и порядке) Не забудь сделать резервную копию. Удачи!

    Ответить

  3. BloggerMen

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

    Ответить

  4. Webliberty

    BloggerMen, все будет хорошо, на себе проверял. Будет интересно узнать результаты!

    Ответить

  5. Nodar Giorgadze

    Интересно, только у меня SQL-запрос не выполнился. Нажал выполнить, спросило уверен ли я, а потом просто ничего не происходит — не выводятся результаты запроса. Неужели у меня нечего чистить? 🙂

    Ответить

  6. Webliberty

    Nodar Giorgadze, если ничего не произошло, вероятно чистить нечего, т.к. если бы запрос был неправильным, то возникнет ошибка. Может Вы пользуетесь кэширующими (оптимизирующими и пр.) плагинами?

    Ответить

  7. armid

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

    Ответить

  8. Ahawks

    Почистил наконец по твоему методу БД 326 строк удалено) Надеюсь, это пошло во благо) Что-то на новом хостинге блог стал медленнее, надо будет поработать над его скоростью.

    Ответить

  9. Webliberty

    Ahawks, даже не сомневайся) Чтобы блог работал быстрее попробуй оптимизировать картинки, сжать javascript, почисти исходный код, оптимизируй CSS и т.д. Много всего можно попробовать.

    Ответить

  10. Татьяна

    Почистила, 355 строк удалено. Надеюсь, что все будет работать быстрее.

    Ответить

  11. Webliberty

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

    Ответить

  12. Мишка на сервере

    Оптимизация вещь довольно таки не простая, тут главное не перестараться, а то можно всех посетителей спугнуть и тогда сайт без будущего 😉

    Ответить

  13. Webliberty

    Мишка на сервере, на то и делается резервная копия, чтобы откатить изменения назад в случае чего)

    Ответить

  14. Яна

    Денис, я Вам написала письмо, пока не получила ответа, руки чешутся попробовать решить мою проблему самой)

    У меня при попытке зайти на блог иногда выдает «Ошибка установки соединения с базой данных». С хостингом все в порядке — остальные мои блоги работают без проблем, то есть, проблема с базой данных. Мне ее посоветовали почистить. Бекап весит 16 мб, то есть, если я сделаю ошибку в таблице, то не знаю, как импортировать такой большой бекап. Поэтому боюсь сама рисковать и оптимизировать таблицы — за три года туда заглядывала только один раз, и то потому что не могла зайти по паролю, нужно было его изменить. Короче, я нуждаюсь в помощи профессионала. Чешу руки, но начать что-то делать не решаюсь 🙁

    Кстати, а Вы мое письмо получили? Я его отправила по форме обратной связи. Очень жду ответа, очень 🙂

    Ответить

  15. Webliberty

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

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

    Также я рекомендую воспользоваться этими советами, чтобы снизить объем базы данных. Письмо получил)

    Ответить

  16. Яна

    А я уже попробовала, пока Вас дожидалась. Действительно, ничего не случилось. Проблема с плохой связью с базой данных исчезла до того, как я почистила таблицу, поэтому, возможно, действительно что-то было на хостинге. Но блог пока не стал работать быстрее, буду изучать дальше Ваш блог и оптимизировать свой, чистить другие таблицы БД и т.д. и т.п. Спасибо Вам за блог и за обратную связь — все очень важное)

    Ответить

  17. Жанна

    У меня проблема «Так вот, из моего примера Вы уже поняли, что WordPress хранит в базе данных старые адреса страниц и при их смене производит редирект на новый адрес» не исчезла 🙁

    Ответить

  18. Webliberty

    Жанна, у Вас быть может настроен редирект с помощью плагина какого-нибудь?

    Ответить

  19. Otshelnik-fm

    Выполнил по вашему методу — 7000 строк нашел и удалил это — 300 килобайт из 30 мегабайтной базы. Эти килобайты то конечно фигня (1%), но вот 7000 строк… Вообщем не жалею)

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

    Ответить

  20. Дмитрий

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

    Ответить

  21. Webliberty

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

    Ответить

  22. Виталий

    Добрый вечер!

    Спасибо за статью, прочитал и сразу внедрил в жизнь, т.е. почистил таблицу wp_postmeta, удалено 243 строки + оптимизировал данную таблицу, проблем с работой сайта нет 🙂

    Хочу и дальше внедрять Ваши статьи в жизнь!!!

    Посмотрел другие таблицы, что-то беспокоит wp_redirection_logs, уж больно большой объём 3.4 МБ, можно ли и её почистить или это нормально для этой таблицы?

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

    Очень прошу помочь, т.к. хочу закончить чистку БД и перейти к ускорению сайта по Вашим статьям.

    Спасибо за помощь, с уважением, Виталий

    Ответить

  23. Webliberty

    Здравствуйте, Виталий! Таблица wp_redirection_logs по-умолчанию не принадлежит WordPress (стандартный список), скорее всего ее использует плагин Redirection или иной для настройки редиректов. Вы используете подобный плагин? Может раньше использовали?

    Чтобы разобраться с meta-ключами мне также понадобится список установленных тем и плагинов. При желании можете отправить, попробую оценить)

    Ответить

:) ;) :D :( :cry: :| :o :P 8-) :oops: :roll: :idea:

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