Очистка, оптимизация и ускорение базы данных WordPress
В процессе эксплуатации блога на WordPress его база данных постепенно засоряется различной ненужной информацией: остатками удалённых плагинов, черновиками, спам-комментариями и другими устаревшими записями.
Это приводит к увеличению её размера и снижению производительности сайта. В этой статье разберём, как очистить базу данных WordPress и поддерживать её в оптимальном работоспособном состоянии.
Почему важна оптимизация базы данных? Если база данных занимает много места, то это напрямую влияет на скорость работы сайта в целом, включая наиболее значимые показатели качества:
- Скорость загрузки страниц — медленные SQL-запросы увеличивают время отклика сервера.
- Производительность сервера — лишние данные нагружают ресурсы хостинга.
- Резервное копирование — бэкапы увеличиваются в размере и требуют больше времени на создание и восстановление.
- Общее удобство работы — администрирование сайта затрудняется, а поиск данных усложняется.
Удаление устаревших значений из таблицы wp_postmeta
Проблема состоит в том, что каждый раз при установке и активации нового плагина или темы WordPress создаёт дополнительные метаданные. После удаления тем и плагинов в таблице wp_postmeta нередко остаются ненужные записи.
Начинающие блогеры десятками загружают новые плагины, пробуют одни и заменяют другими, несмотря на то, что большинство тривиальных задач решается вовсе без плагинов. В этой статье я расскажу как можно удалить устаревшие значения из базы данных.
Для начала очистки открываем phpMyAdmin, выбираем базу данных, находим таблицу wp_postmeta и напротив в этой же строке нажимаем Структура:
Видим такие имена параметров, как meta_id, post_id, meta_key и другие. Нас интересует meta_key — находим строку с таким именем и нажимаем на Уникальные значения:
В результате мы увидим номера строк, а также уникальные значения мета-ключей. Здесь начинается самое интересное — необходимо пристально их изучить и выявить «лишние». Очень важно быть особо внимательными на этом этапе, потому что никто кроме вас не сможет определить, какие именно строки являются «лишними»!?
Некоторые мета-ключи содержат стандартные настройки WordPress, другие сохранены плагинами и темами. В моём примере я привел часть скриншота, на котором присутствуют следующие строки и уникальные значения:
_aioseo_description— плагин All In One SEO Pack_aioseo_keywords— плагин All In One SEO Pack_aioseo_title— плагин All In One SEO Pack_edit_last— время последнего редактирования записи (WordPress)_edit_lock— метка о текущем редактировании записи (WordPress)_encloseme— обработка видео и аудио ссылок в контенте (WordPress)
Анализируем список значений и удаляем те, которые принадлежат давно удалённым плагинам. Допустим, в качестве примера, я намеренно удалил плагин All In One SEO Pack, а после удаления в базе данных остались метаданные, которые больше не нужны.
Чтобы найти эти устаревшие метаданные можно воспользоваться формой поиска в phpMyAdmin. Нажмите на вкладку Поиск и затем напротив поля с названием meta_key в поле Значение напишите одно из найденных лишних уникальных значений. В моём примере это _aioseo_title. Затем нажимаем на кнопку Вперёд:
В итоге будут найдены строки, которые содержат эти устаревшие метаданные, их без особой сложности можно удалить из базы данных WordPress:
Рекомендую всем читателям как можно раньше провести ревизию своих блогов, выявить устаревшие плагины (не обновляемые более двух лет) и попытаться найти альтернативную замену! 💡
Очистка таблицы wp_commentmeta
Со временем, по мере наполнения блога новыми записями, растёт количество комментариев и закономерно снижается свободное дисковое пространство на сервере. Зачастую этому способствует несоразмерно объемная база данных.
Однажды я обратил внимание на такую ситуацию: таблица wp_commentmeta стала занимать чрезвычайно много дискового пространства, хотя самих комментариев было не много. Оказалось, одной из основных причин, почему база данных занимает много места, может стать наличие огромного числа спам-комментариев и установленный плагин Akismet Anti-spam: Spam Protection.
Акисмет — это отличный плагин для борьбы со спамом в комментариях, но к каждому из них он добавляет свои метаданные и записывает их в таблицу wp_commentmeta. Абсолютно все комментарии, даже помеченные как спам, несут с собой ненужную информацию, а после очистки спама и корзины эти метаданные не удаляются и продолжают занимать место.
Их можно удалить из таблицы wp_commentmeta базы данных WordPress. Для этого нужно выбрать базу данных в phpMyAdmin, перейти на вкладку SQL и в появившемся окне вставить следующий SQL-запрос:
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);После чего нажать Вперёд. Возвращаясь на начальную страницу phpMyAdmin я отметил ощутимое сокращение размера базы данных, за счёт очистки таблицы wp_commentmeta. Таблица уменьшилась в размере почти в 5 раз!
Удаление старых ревизий и автосохранений
WordPress сохраняет каждую версию записи (редакцию, ревизию), что со временем увеличивает размер базы данных. Для очистки базы данных от старых данных используйте SQL-запрос:
DELETE FROM wp_posts WHERE post_type = 'revision';Чтобы отключить сохранение ревизий, добавьте в файл wp-config.php:
define('WP_POST_REVISIONS', false);Более подробную информацию о редакциях записей на WordPress, их предназначении и настройке читайте в отдельной статье.
Удаление старых slug-записей
Если вы изменяли URL записей, то WordPress сохранял старые адреса для редиректа в мета-ключе _wp_old_slug. Он содержит информацию о предыдущем URL-адресе страницы, если были изменения.
Чтобы удалить старые slug-записи, используйте SQL-запрос:
DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';Очередной пример из жизни: когда я создавал самую первую запись на своём блоге, то это была не новая запись, а редактировался пост по умолчанию, созданный в процессе установки WordPress с названием «Привет мир!» и ссылка имела вид: https://webliberty.ru/privet-mir/
Со временем, подумав о том, что на каждом втором блоге будет точно такой же URL, я решил его изменить и сделал так: https://webliberty.ru/moy-pervyiy-post/
Прошло время, поисковые системы уже переиндексировали заново данную страницу с новым URL, только Google никак не хотел выкидывать старый адрес из поиска, несмотря на то, что при его вводе в адресную строку браузера происходил 301 редирект на новый адрес 🙁.
Лишь только после удаления _wp_old_slug сервер стал отдавать старый URL с ошибкой 404 (страница не найдена) и Google наконец-то выкинул несуществующую страницу из поиска.
Удаление времени последнего редактирования
Мета-ключ _edit_last содержит информацию о времени последнего редактирования записи. Чтобы удалить эту информацию, используйте SQL-запрос:
DELETE FROM wp_postmeta WHERE meta_key = '_edit_last';У меня на блоге для каждой записи выведена дата публикации и дата последнего редактирования. Для чего это нужно? Допустим, статья опубликована очень давно, но постоянно обновляется и дополняется, таким образом пользователи увидят, что статья по прежнему актуальна на данный момент. Я не удаляю эти данные.
Удаление информации о редактировании
Мета-ключ _edit_lock сохраняет метку времени и ID пользователя, который редактирует запись. Благодаря этому в консоли WordPress мы можем видеть, что запись в текущий момент редактируется другим пользователем. Актуально, если на сайте зарегистрировано несколько авторов.
Чтобы удалить эту информацию, используйте SQL-запрос:
DELETE FROM wp_postmeta WHERE meta_key = '_edit_lock';Оптимизация базы данных
После удаления ненужных данных следует оптимизировать таблицы, чтобы освободить место. Для проведения этой процедуры открываем phpMyAdmin, выбираем базу данных, отмечаем все таблицы и с отмеченными проводим обслуживание — Оптимизировать таблицу:
Или чтобы оптимизировать только стандартные таблицы базы данных WordPress, используйте SQL-запрос:
OPTIMIZE TABLE `wp_commentmeta`, `wp_comments`, `wp_links`, `wp_options`, `wp_postmeta`, `wp_posts`, `wp_termmeta`, `wp_terms`, `wp_term_relationships`, `wp_term_taxonomy`, `wp_usermeta`, `wp_users`Плагины для очистки и оптимизации базы данных
Для автоматической очистки базы данных можно использовать плагины для WordPress, например, Advanced Database Cleaner.
Плагин помогает очистить базу данных, удалив ненужные данные, которые вынуждают сайт работать медленно. Среди заявленных функций:
- Удаление ревизий, черновиков, временных записей.
- Оптимизация таблиц базы данных.
- Удаление неиспользуемых meta-ключей.
И этим огромный список полезных функций не ограничивается, более подробно читайте в описании плагина на официальной странице репозитория. Однако помните, что плагины не всегда безопасны и могут удалить важные данные! Всегда делайте резервную копию перед использованием!
Автоматизация очистки через Cron
Чтобы автоматизировать процесс очистки и делать это регулярно, можно добавить скрипт в файл functions.php, который раз в неделю будет удалять старые слаги и ревизии:
if (!wp_next_scheduled('weekly_db_cleanup')) {
wp_schedule_event(time(), 'weekly', 'weekly_db_cleanup');
}
add_action('weekly_db_cleanup', function() {
global $wpdb;
$wpdb->query("DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug'");
$wpdb->query("DELETE FROM wp_posts WHERE post_type = 'revision'");
});
Подведём итог
Чистка базы данных WordPress очень важна для поддержания работоспособности и высокой производительности сайта. Выполняйте её регулярно, делайте резервные копии перед изменениями. В случае повреждения базы данных, воспользуйтесь одним из способов восстановления. Это поможет вашему сайту оставаться актуальным, быстрым и стабильным даже при большом количестве контента.
И напоследок, хочу обратить внимание, что в моём примере приведен стандартный префикс wp_ для таблиц, у вас он может отличаться. Надеюсь, мне удалось все понятно объяснить, если появились вопросы — не стесняйтесь и смело задавайте в комментариях!
С этой проблемой можно справится более гуманно, не тестировать новые возможности на основном блоге, а завести для этих целей отдельный блог на локальном компьютере или на хостинге.
Хорошо для этих целей подходит cishost.ru там есть тариф специально для этих целей цена 10 рублей в месяц (основной проект на этом хостинге держать не советую служба поддержки не круглосуточная). А в общем статья не лишена пользы.
Ответить
Максим, согласен в том плане, что основной блог не стоит использовать в качестве тестовой площадки. Но все же, тем кто раз в пол года решит опробовать новый плагин нет смысла держать дополнительный хостинг и тем более оплачивать его. Как вариант — локальный хост, например на денвере.
Ответить
Очень полезная статья, попробую сегодня завтра этот метод, а то очень часто изменяю то или другое на блогах. Спасибо за материал.
Ответить
Ahawks, базу данных можно назвать «сердцем» блога, это та составляющая, без которой не обойтись, поэтому следует содержать ее в чистоте и порядке) Не забудь сделать резервную копию. Удачи!
Ответить
Никогда не чистил базу. Теперь поэкспериментирую, надеюсь все обойдется без приключений.
Ответить
BloggerMen, все будет хорошо, на себе проверял. Будет интересно узнать результаты!
Ответить
Интересно, только у меня SQL-запрос не выполнился. Нажал выполнить, спросило уверен ли я, а потом просто ничего не происходит — не выводятся результаты запроса. Неужели у меня нечего чистить? 🙂
Ответить
Nodar Giorgadze, если ничего не произошло, вероятно чистить нечего, т.к. если бы запрос был неправильным, то возникнет ошибка. Может Вы пользуетесь кэширующими (оптимизирующими и пр.) плагинами?
Ответить
Nodar Giorgadze, если у вас используется не стандартный префикс таблиц
wp_, тогда вам нужно его поменять в запросе.Ответить
Почистил наконец по твоему методу БД 326 строк удалено) Надеюсь, это пошло во благо) Что-то на новом хостинге блог стал медленнее, надо будет поработать над его скоростью.
Ответить
Ahawks, даже не сомневайся) Чтобы блог работал быстрее попробуй оптимизировать картинки, сжать javascript, почисти исходный код, оптимизируй CSS и т.д. Много всего можно попробовать.
Ответить
Почистила, 355 строк удалено. Надеюсь, что все будет работать быстрее.
Ответить
Татьяна, можете не сомневаться, чистка базы данных пойдет только на пользу блогу. Я занимаюсь оптимизацией подобным образом примерно раз в неделю — в итоге база не успевает разрастаться.
Ответить
А эта очистка не опасна для сайта? 💡
Ответить
Антон, нет, не опасна если Вы имеете в виду запрос к базе данных из рекомендуемого поста. Не забывайте делать резервные копии перед изменениями и все будет в порядке!
Ответить
Мощно! Я люблю mysql и phpmyadmin. В работе с сайтом это отличный инструмент, все как на ладони. Если знать большинство команд, то работа намного упрощается. Наверное, в скорем, напишу небольшую заметку про mysql/
СпасибО! 😉
Ответить
Денис, спасибо за такую полезную информацию. Обязательно этим займусь. На самом деле спама очень много.
Ответить
Арина, конечно займитесь, даже хотя бы в профилактических целях следует проверять БД, оптимизировать, чистить, обязательно делать бэкапы.
Владимир, инструмент действительно хороший, можно вдоль и поперек перебрать базу данных и изменять настройки самого движка прямо там. Неоднократно приходилось выполнять запросы для массового редактирования и даже восстанавливать целые посты с комментариями к ним, когда «случайно» доигрался 😀
Ответить
И такое у меня было, доигрался серьезно однажды, введя команду DELETE FROM table WHERE id < 1000, а нужно было удалить десяток записей после 1000… Следовательно знак ставить не 😀
Ответить
Владимир, всякое бывает) В таких ситуациях главное не паниковать, как многие начинают, да что там говорить, я и сам начинаю паниковать если что-то не так пошло. Главное собраться, успокоиться и подумать как исправить. Для этого конечно же потребуется резервная копия базы данных, которую желательно делать вручную и хранить на своем компьютере.
Ответить
На мое счастье, у меня была резервная копия. Я жутко побелел, думал идти писать заявление 😀 Но вида не подал, чтобы не спросили, а что это я такой взволнованный.
Ответить
Денис, здравствуйте…У меня вчера пришло сообщение с хостинга Тайм Вэб, что дисковое пространство превышено и предлагают поменять тариф. Новый тариф предполагает оплату только за весь год, а меня это сейчас не устраивает 😐 Подскажите, как справиться с проблемой.
Ответить
Лесоруб, странные у них правила с оплатой, обычно можно выбирать на сколько месяцев продлевать. Очистите базу данных этим способом и дополнительными, которые приведены в посте.
А также при вставке изображений предварительно их сжимайте перед загрузкой (уже опубликованные также можно сжать). Далее если у Вас используются плагины для создания резервных копий, то вероятно они их сохраняют на сервере, что тоже сокращает свободное дисковое пространство.
Плагины кэширования в Вашем случае тоже лучше не использовать, т.к. все страницы сохраняются в папке кэша на сервере. Одним словом, избавьтесь от лишнего, если нет возможности перейти на новый тариф. Или смените хостинг-провайдера на того, у которого можно продлевать на столько месяцев, сколько понадобиться.
Ответить
У меня вообще данная таблица 16 мб весит. Надо очистить. Только ты забыл про префикс написать, не у всех он wp_
Ответить
Да почти у всех, мало кто меняет при установке. Наверное единицы. Я работаю по службе с сотней вордпрессов, только у одного префикс не wp_… 😉
Ответить
И от меня спасибо, Денис! В жизни не додумалась бы сама, что базу данных надо чистить))) А добра там, да, скопилось…. 😮
Ответить
Лесоруб, здравствуйте! Возможно что место превысил Ваш лог ошибок, либо еще какой-нибудь лог. Отключить или поинтересоваться можно, написав хостеру. Ну можно просто сменить хостинг, Locum очень хороший выбор. И цены нормальные и скорость… Я доволен!
Ответить
apisklov, правильно замечание, благодарю! В коде запроса нужно изменить префикс на свой, если он был изменен, а не применен по умолчанию.
Владимир, а кем работаешь, если не секрет? Вот бы мне такую работу, чтобы и увлечение и основное занятие совпадали ❓
Ответить
Полезно! Поудалял комментарии и у себя на некоторых сайтах WordPress
Ответить
Оптимизация вещь довольно таки не простая, тут главное не перестараться, а то можно всех посетителей спугнуть и тогда сайт без будущего 😉
Ответить
Мишка на сервере, на то и делается резервная копия, чтобы откатить изменения назад в случае чего)
Ответить
Денис, а комментарии не удалятся? А то потом будет проблема с их восстановлением.
Ответить
Людмила, нет не удалятся, никаких проблем после чистки не возникнет, если сомневаетесь — сделайте резервную копию.
Ответить
У меня резервные копии делаются на автомате. Только я еще не пользовалсь ими для восстановления. Надеюсь, что и дальше не придется. А почистить надо. Накопилось много всего. ❗
Ответить
Денис, я Вам написала письмо, пока не получила ответа, руки чешутся попробовать решить мою проблему самой)
У меня при попытке зайти на блог иногда выдает «Ошибка установки соединения с базой данных». С хостингом все в порядке — остальные мои блоги работают без проблем, то есть, проблема с базой данных. Мне ее посоветовали почистить. Бекап весит 16 мб, то есть, если я сделаю ошибку в таблице, то не знаю, как импортировать такой большой бекап. Поэтому боюсь сама рисковать и оптимизировать таблицы — за три года туда заглядывала только один раз, и то потому что не могла зайти по паролю, нужно было его изменить. Короче, я нуждаюсь в помощи профессионала. Чешу руки, но начать что-то делать не решаюсь 🙁
Кстати, а Вы мое письмо получили? Я его отправила по форме обратной связи. Очень жду ответа, очень 🙂
Ответить
Яна, добрый день, извиняюсь за задержку с ответом. Кстати, насчет хостинга — зря Вы сразу же скинули со счетов возможную в нем проблему, я бы в первую очередь посоветовал обратиться именно к хостеру.
Без опаски пользуйтесь данным способом очистки базы данных, никаких печальных последствий не возникнет. Я наверное уже писал выше, что провожу данную операцию раз в неделю. Как видите, уже прошло много времени со дня публикации этого поста и все в порядке, все работает)
Также я рекомендую воспользоваться этими советами, чтобы снизить объем базы данных. Письмо получил)
Ответить
А я уже попробовала, пока Вас дожидалась. Действительно, ничего не случилось. Проблема с плохой связью с базой данных исчезла до того, как я почистила таблицу, поэтому, возможно, действительно что-то было на хостинге. Но блог пока не стал работать быстрее, буду изучать дальше Ваш блог и оптимизировать свой, чистить другие таблицы БД и т.д. и т.п. Спасибо Вам за блог и за обратную связь — все очень важное)
Ответить
Спасибо за статью! У вас она весила 5.1 Мб, у кого то 16 мб, значит у меня рекорд)))
wp_commentmeta весила 135 метров, вся таблица около 145. Удалено 36740 строк.
Ответить
Михаил, вот это да! Наверное с таким размером БД очень сложно восстанавливать из архива, ведь есть ограничения на размер загружаемого файла… Скорее всего приходится прибегать к помощи поддержки хостера…
Ответить
Хотела почистить базу но у меня вместо wp_commentmeta написано wscrp_commentmeta. Что делать?
Ответить
Денис, у меня такая проблема — моя резервная копия весит 16 мб. Именно поэтому я и пытаюсь почистить базу. Но боюсь, что я потом не смогу втиснуть такой большой бекап в вордпресс, там же нужен файл, размером не больше 8 мб. Что делать?
Спасибо за блог. Он просто сокровище.
Ответить
Людмила, используйте в запросе имя своей таблицы. У Вас просто задан свой префикс к таблицам, по умолчанию он wp_
Выполните запрос:
DELETE FROM wscrp_commentmeta WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments)Не забудьте про резервную копию! Это так, на всякий случай 🙂
Ответить
Яна, обратиться за помощью в техподдержку хостинга, если понадобиться восстановление. И конечно же просто проконсультируйтесь у них как поступать в таких ситуациях. У меня сейчас база около 5 Мб, пока не сталкивался с этим, но скоро по всей видимости придется)
Ответить
У меня проблема «Так вот, из моего примера Вы уже поняли, что WordPress хранит в базе данных старые адреса страниц и при их смене производит редирект на новый адрес» не исчезла 🙁
Ответить
Жанна, у Вас быть может настроен редирект с помощью плагина какого-нибудь?
Ответить
А вот я даже туда не суюсь дальше, боюсь и обхожу стороной, еле как перенес свою базу на свой хостинг, а оптимизировать и менять, уж точно испорчу 😈
Ответить
Алем, думаешь я там часто ковыряюсь? 😈 Так, пару раз пришлось покопаться, когда с древовидными комментариями начудил, да так, что комментарии к одной записи перебежали на другую страницу, пришлось разбираться…)
Ответить
Выполнил по вашему методу — 7000 строк нашел и удалил это — 300 килобайт из 30 мегабайтной базы. Эти килобайты то конечно фигня (1%), но вот 7000 строк… Вообщем не жалею)
PS: я загружаю на свой блог очень много картинок, поэтому такая разница в результатах. Ну и то что я отказался от вордпрессовской медиабиблиотеки.
Ответить
А вот расшифровать таблицы из под оставленных плагинов оказалось самым трудным. Не решилась. А комментарии от спама регулярно чищу, последний раз 4 мб удалила.
Ответить
Татьяна, правильно сделали, если нет в чем то уверенности, то лучше не трогать, к тому же если все прекрасно работает. Я сам в последнее время придерживаюсь такой позиции — если есть сомнения, значит стоит еще раз все взвесить, а не делать скоропалительных решений.
База данных — это «сердце» блога, из нее подгружаются данные при динамическом построении страницы, поэтому ее нужно беречь 🙂
Ответить
Webliberty, что комментарии к одной записи перебежали на другую страницу, — Вот с этого места — можно подробнее? У меня глюки какие-то, комментарии пишутся и отображаются в ней правильно. Но на страницах сами комментарии перебегают черт знает куда…
Ответить
Михаил, сложно сказать, у меня это было после манипуляций с этими комментариями. Несколько убежало и менял в базе их id, чтобы перенести к другому посту. Т.е. проблема не массовая и с тех пор не появлялась. Если у Вас всегда такое происходит — попробуйте по отключать плагины, может какой-то из них глючит…
Ответить
Здорово! Очень понятно пишете! Может дойдут и у меня руки заняться оптимизацией базы данных, а пока статью в закладки.
Хотя если по-большому счету, то весь ваш сайт нужно брать в закладки и постепенно наводить порядок на блоге.
Кстати, не предлагаете ли вы подобные услуги за деньги?
Ответить
Спасибо! Подобных платных услуг, к сожалению, не оказываю 😳
Ответить
Полезно! Денис, спасибо! Давно не чистил БД, скорее всего тоже висят старые данные в ней от плагинов, так как многое давно перевел на код. Надо на досуге заняться, поглядеть 😉
Ответить
Привет, Сергей! Я вот люблю все изучать, а тут как-то делал резервные копии и решил посмотреть проверить базы данных, мало ли следы взлома обнаружу… В последнее время больно много «левых» запросов идет к админке судя по логам, решил перестраховаться.
Все таблицы просмотрел — нашел лишние, которые сохранились даже после удаления плагинов, и в стандартных обнаружил их следы. Поэтому решил почистить, чтобы был порядок)
Ответить
Webliberty, кстати у меня тоже одно время было много запросов и нагрузка, проверил логи оказалось пытаются взломать админку, предпринял ряд действий по защите, несколько видов. В итоге сейчас если судить по логам все гораздо лучше стало, запросы левые пропали и нагрузка уменьшилась.
Ответить
Аналогично, хостер даже письма прислал дважды, это было в августе. Я закрыл доступ к админке с помощью двойной авторизации, сейчас вроде поутихло…
Ответить
Вовремя нашёл ваш блог — тема как раз кстати. Уже начал ломать голову над тем, как избавиться от мусора. Спасибо автору за тщательную инструкцию. Помогла.
Ответить
Привет Денис.
Вы тут подняли тему в комментариях. А как проверить откуда идёт нагрузка на сервер. И вообще комплексные, действенные меры по снижению нагрузок на сервер, а то хостер грозится отключить сайт.
И ещё вопрос: плагин удалил из админки, почистил базу, зашёл через файлзиллу и в папке с плагинами обнаружил остались файлы от плагинов типа: cforms-ru_RU.mo, wp-db-backup-ru_RU.po, и т.д. что за файлы (вроде бы файлы русификации)? я так понял эти остатки тоже надо удалять ручками?
Ответить
Привет, Дмитрий, проверить можно по логам сервера. Посмотреть с какого IP часто подключаются (возможно идет брутфорс атака) и закрыть для него подключение. Также не плохо сделать двойную авторизацию при входе в админку. Естественно кэширование и прочие мероприятия по ускорению сайта.
Да это файлы русификации плагинов. Если они больше не используются и удалены, то файлы тоже можно удалить.
Ответить
С автором полностью согласен — ПЕРЕД ТЕМ КАК ЧТО-ТО ДЕЛАТЬ С БАЗОЙ ДЕЛАЙТЕ БЕКАП! А так у WP есть один хороший плагин, который также чистит базу чуть ли не в режиме реального времени, называется — WP-Optimize. Посмотрите полезный плагин!
Ответить
WP-Optimize хороший плагин, подойдет нетривиальных задач, однако действия описанные в статье ни один плагин не выполнит. Так что плагин такой можно установить и польза будет непременно, но и ручками тоже приходится поработать)
Ответить
Я тоже использую WP-Optimize, но Ваше решение проблемы удаления устаревших значений очень интересно, будем пробовать… 😉
Ответить
Добрый день! Попробовал данный метод в итоге база слетела, сайт не работает. Естественно восстановил из резервной копии. Будьте острожнее с данным методом.
Ответить
Само собой разумеется, предупреждение о необходимости сделать бэкап размещено. Хотя никто до сих пор о проблемах не сообщал, Вы первый… Да и сам я регулярно провожу чистку БД таким образом.
Ответить
Большое спасибо, Денис. Сразу зашла и удалила несколько строк, но есть заголовки значения которых не знаю.
Вообще-то мне нужно сделать удаление большого куска кода на сайте. Это громадный файл шифрования нескольких плагинов. Обращалась на хостинг, говорят, что не нужно удалять. Что это нарушит корректную работу плагина bwp minyfy. Что-то не очень этому верю, потому что валидатор это фиксирует, как ошибку. Программа Xenus обозначает это ошибкой 404. Как это убрать пока не знаю. Может быть подскажете 😉
Ответить
Ксенья Юрьевна, если встречаются неизвестные строки, то их лучше не трогать, чтобы не навредить. По поводу файла шифрования не понял, если еще актуально — отправьте мне письмо на почту, попробую разобраться.
Ответить
Здравствуйте, Webliberty!
Огромное спасибо за нужную статью — прям в тему! 😎
Вы правильно написали, что начинающие устанавливают кучу плагинов, а со временем их удаляют, как раз про меня) А «следы» плагинов и другой мусор накапливается 🙁
Поэтому пришла очередь почистить БД, но в папке Плагины, что на сервере, обнаружил только установленные у меня плагины (лишних нет) и внимательно просмотрел найденные строки в meta_key никаких подозрительных значений (насколько я понимаю) не нашёл. Неужели удалённые плагины полностью удалились? Или может они ещё где-нибудь спрятались?
Ещё вопрос, следов плагинов не нашёл, но нашёл значения _wp_old_slug, из название ясно, что это надо удалить, но вот вопросик: только эти значения? Как я понял все они идут «в связке» с другим значением, имеющим одинаковый номер, например: 469
Нужно удалять только значение
_wp_old_slugили же вместе с вышеуказанным значением_yoast_wpseo_metakeywords?Ещё раз спасибо за толковые и профессиональные статьи и помощь,
С уважением, Виталий
Ответить
Здравствуйте, Виталий. Правильно написанные плагины убирают весь мусор за собой при удалении, но есть неприятные исключения, ради которых приходится вручную ковыряться в базе данных. Возможно, плагины полностью были удалены без следов, возможно не удалось их вычислить.
Что касается
_wp_old_slug, то здесь вручную лучше ничего не делать, слаги хранятся для всех записей, соответственно, чем больше записей, тем больше таких значений.Ответить
Добрый вечер!
Спасибо за статью, прочитал и сразу внедрил в жизнь, т.е. почистил таблицу wp_postmeta, удалено 243 строки + оптимизировал данную таблицу, проблем с работой сайта нет 🙂
Хочу и дальше внедрять Ваши статьи в жизнь!!!
Посмотрел другие таблицы, что-то беспокоит wp_redirection_logs, уж больно большой объём 3.4 МБ, можно ли и её почистить или это нормально для этой таблицы?
Также прошу Вас, своим опытным взглядом глянуть на строки meta_key, потому что я не очень-то и понял есть ли удалённые плагины там 🙁 При Вашем согласии, готов скинуть Вам строки meta_key на форму обратной связи.
Очень прошу помочь, т.к. хочу закончить чистку БД и перейти к ускорению сайта по Вашим статьям.
Спасибо за помощь, с уважением, Виталий
Ответить
Здравствуйте, Виталий! Таблица wp_redirection_logs по-умолчанию не принадлежит WordPress (стандартный список), скорее всего ее использует плагин Redirection или иной для настройки редиректов. Вы используете подобный плагин? Может раньше использовали?
Чтобы разобраться с meta-ключами мне также понадобится список установленных тем и плагинов. При желании можете отправить, попробую оценить)
Ответить
Спасибо за статью!
Почистил и я свою базу данных от хлама, ничего сложно в этом нет.
Результат есть, загрузка страниц стала гораздо быстрее!
Ответить