Удаление лишних meta-ключей WordPress SQL запросом
Здравствуйте! Когда-то я уже затрагивал тему очистки базы данных от старых таблиц и строк, которые уже потеряли актуальность. И речь тогда шла про «мусор», оставляемый различными плагинами после их удаления.
Сейчас я затрону другую техническую сторону, связанную с базой данных, но уже касающуюся непосредственно самой работы движка WordPress, а точнее некоторой особенности при публикации записей.
Наверняка Вам не раз приходилось пересохранять и публиковать посты заново, допустим после прочтения опубликованного материала нашли грамматическую ошибку или просто решили подправить… Да все что угодно! Я не раз и не два иногда обновляю свои записи.
И каждый раз Вордпресс записывает в базу данных дату и время последнего редактирования записи, старые адреса ссылок и прочую ненужную информацию — все это несомненно загромождает базу данных и замедляет работу. Чтобы навести порядок во всем этом не потребуется особых знаний и умений, достаточно всего лишь выполнить SQL запрос к базе данных WordPress в панели PhpMyAdmin.
SQL запрос к базе данных WordPress
Сделали бэкап базы данных? Отлично! Тогда можно приступать! Необходимо выполнить следующий запрос к базе данных:
DELETE FROM `wp_postmeta`
WHERE `meta_key` IN('_edit_lock', '_edit_last','_wp_old_slug')Выполняя данный запрос мы удаляем из таблицы wp_postmeta следующие ключи:
_edit_lockОказывается, если для пользователей открыт доступ для написания постов на Вашем блоге, т.е. в консоли управления на вкладке «Параметры» в пункте «Общие» роль нового пользователя будет обозначена как Автор, то данный параметр будет отвечать за время в течение которого он может изменять свое сообщение в течение указанного срока. В базе данных значение может выглядеть так:edit_lock = 60
В данном примере число 60 говорит о том, что у пользователя есть 60 минут на редактирование своего сообщения с момента публикации. Данный параметр считаю абсолютно бесполезным в том случае, если владелец сайта является единственным автором статей._edit_lastДанный параметр содержит информацию о времени последнего редактирования записи. Не несет в себе смысловой нагрузки и его также можно удалять._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-запроса, она ее выдержала и чувствует себя замечательно, как видите все функционирует.
Очень полезная статья, попробую сегодня завтра этот метод, а то очень часто изменяю то или другое на блогах. Спасибо за материал.
Ответить
Ahawks, базу данных можно назвать «сердцем» блога, это та составляющая, без которой не обойтись, поэтому следует содержать ее в чистоте и порядке) Не забудь сделать резервную копию. Удачи!
Ответить
Никогда не чистил базу. Теперь поэкспериментирую, надеюсь все обойдется без приключений.
Ответить
BloggerMen, все будет хорошо, на себе проверял. Будет интересно узнать результаты!
Ответить
Интересно, только у меня SQL-запрос не выполнился. Нажал выполнить, спросило уверен ли я, а потом просто ничего не происходит — не выводятся результаты запроса. Неужели у меня нечего чистить? 🙂
Ответить
Nodar Giorgadze, если ничего не произошло, вероятно чистить нечего, т.к. если бы запрос был неправильным, то возникнет ошибка. Может Вы пользуетесь кэширующими (оптимизирующими и пр.) плагинами?
Ответить
Nodar Giorgadze, если у вас используется не стандартный префикс таблиц
wp_, тогда вам нужно его поменять в запросе.Ответить
Почистил наконец по твоему методу БД 326 строк удалено) Надеюсь, это пошло во благо) Что-то на новом хостинге блог стал медленнее, надо будет поработать над его скоростью.
Ответить
Ahawks, даже не сомневайся) Чтобы блог работал быстрее попробуй оптимизировать картинки, сжать javascript, почисти исходный код, оптимизируй CSS и т.д. Много всего можно попробовать.
Ответить
Почистила, 355 строк удалено. Надеюсь, что все будет работать быстрее.
Ответить
Татьяна, можете не сомневаться, чистка базы данных пойдет только на пользу блогу. Я занимаюсь оптимизацией подобным образом примерно раз в неделю — в итоге база не успевает разрастаться.
Ответить
Оптимизация вещь довольно таки не простая, тут главное не перестараться, а то можно всех посетителей спугнуть и тогда сайт без будущего 😉
Ответить
Мишка на сервере, на то и делается резервная копия, чтобы откатить изменения назад в случае чего)
Ответить
Денис, я Вам написала письмо, пока не получила ответа, руки чешутся попробовать решить мою проблему самой)
У меня при попытке зайти на блог иногда выдает «Ошибка установки соединения с базой данных». С хостингом все в порядке — остальные мои блоги работают без проблем, то есть, проблема с базой данных. Мне ее посоветовали почистить. Бекап весит 16 мб, то есть, если я сделаю ошибку в таблице, то не знаю, как импортировать такой большой бекап. Поэтому боюсь сама рисковать и оптимизировать таблицы — за три года туда заглядывала только один раз, и то потому что не могла зайти по паролю, нужно было его изменить. Короче, я нуждаюсь в помощи профессионала. Чешу руки, но начать что-то делать не решаюсь 🙁
Кстати, а Вы мое письмо получили? Я его отправила по форме обратной связи. Очень жду ответа, очень 🙂
Ответить
Яна, добрый день, извиняюсь за задержку с ответом. Кстати, насчет хостинга — зря Вы сразу же скинули со счетов возможную в нем проблему, я бы в первую очередь посоветовал обратиться именно к хостеру.
Без опаски пользуйтесь данным способом очистки базы данных, никаких печальных последствий не возникнет. Я наверное уже писал выше, что провожу данную операцию раз в неделю. Как видите, уже прошло много времени со дня публикации этого поста и все в порядке, все работает)
Также я рекомендую воспользоваться этими советами, чтобы снизить объем базы данных. Письмо получил)
Ответить
А я уже попробовала, пока Вас дожидалась. Действительно, ничего не случилось. Проблема с плохой связью с базой данных исчезла до того, как я почистила таблицу, поэтому, возможно, действительно что-то было на хостинге. Но блог пока не стал работать быстрее, буду изучать дальше Ваш блог и оптимизировать свой, чистить другие таблицы БД и т.д. и т.п. Спасибо Вам за блог и за обратную связь — все очень важное)
Ответить
У меня проблема «Так вот, из моего примера Вы уже поняли, что WordPress хранит в базе данных старые адреса страниц и при их смене производит редирект на новый адрес» не исчезла 🙁
Ответить
Жанна, у Вас быть может настроен редирект с помощью плагина какого-нибудь?
Ответить
Выполнил по вашему методу — 7000 строк нашел и удалил это — 300 килобайт из 30 мегабайтной базы. Эти килобайты то конечно фигня (1%), но вот 7000 строк… Вообщем не жалею)
PS: я загружаю на свой блог очень много картинок, поэтому такая разница в результатах. Ну и то что я отказался от вордпрессовской медиабиблиотеки.
Ответить
Добрый день! Попробовал данный метод в итоге база слетела, сайт не работает. Естественно восстановил из резервной копии. Будьте острожнее с данным методом.
Ответить
Само собой разумеется, предупреждение о необходимости сделать бэкап размещено. Хотя никто до сих пор о проблемах не сообщал, Вы первый… Да и сам я регулярно провожу чистку БД таким образом.
Ответить
Добрый вечер!
Спасибо за статью, прочитал и сразу внедрил в жизнь, т.е. почистил таблицу wp_postmeta, удалено 243 строки + оптимизировал данную таблицу, проблем с работой сайта нет 🙂
Хочу и дальше внедрять Ваши статьи в жизнь!!!
Посмотрел другие таблицы, что-то беспокоит wp_redirection_logs, уж больно большой объём 3.4 МБ, можно ли и её почистить или это нормально для этой таблицы?
Также прошу Вас, своим опытным взглядом глянуть на строки meta_key, потому что я не очень-то и понял есть ли удалённые плагины там 🙁 При Вашем согласии, готов скинуть Вам строки meta_key на форму обратной связи.
Очень прошу помочь, т.к. хочу закончить чистку БД и перейти к ускорению сайта по Вашим статьям.
Спасибо за помощь, с уважением, Виталий
Ответить
Здравствуйте, Виталий! Таблица wp_redirection_logs по-умолчанию не принадлежит WordPress (стандартный список), скорее всего ее использует плагин Redirection или иной для настройки редиректов. Вы используете подобный плагин? Может раньше использовали?
Чтобы разобраться с meta-ключами мне также понадобится список установленных тем и плагинов. При желании можете отправить, попробую оценить)
Ответить