Как почистить и оптимизировать базу данных Вордпресс
Со временем в базе данных Вордпресс накапливается много лишней информации. Её объём иногда достигает таких размеров, что сайт начинает спотыкаться и может даже упасть. Сегодня я покажу несколько приёмов по очистке и оптимизации БД Вордпресс.
База данных Вордпресс напоминает шкаф, в котором хранятся все материалы сайта: посты, страницы, их ревизии, комментарии, в том числе и помеченные как спам, а также все настройки тем и плагинов. Поэтому, если сайт используется продолжительное время, скорее всего в его базе данных имеются данные, которые можно удалить.
Хранение бесполезных данных приводит к раздуванию базы данных. Например, зачем хранить настройки темы, которая была удалена много лет назад? Очистка базы данных не только освобождает пространство, но и способствует увеличению скорости работы сайта.
Для Вордпресс существует несколько различных способов оптимизации БД, я покажу несколько полезных запросов MySQL, которые можно выполнить в phpMyAdmin, например. А также расскажу про пару полезных плагинов, которые помогут упростить задачу.
Внимание: Перед любым действием с базой данных обязательно создать резервную копию.
Оптимизация базы данных Вордпресс с помощью phpMyAdmin
Существует несколько способов выполнения SQL-запросов в БД. Самым простым вариантом является phpMyAdmin. Получить к нему доступ обычно можно в панели управления хостингом в разделе «Базы данных».
Внутри phphMyAdmin сразу переходим в раздел SQL.
Здесь мы и будем выполнять все SQL-запросы.
Сразу обращаю внимание, в примерах ниже используется дефолтный префикс таблиц Вордпресс — «wp_» Поэтому, прежде убедитесь, что префиксы таблиц вашей БД такие же. Если нет — просто меняйте их в запросах на свои.
Удалить старые плагины и данные
Начнем с удаления оставшихся данных от удалённых плагинов. В таблице wp_postmeta также можно обнаружить много других ненужных данных, которые можно почистить этим же запросом.
Вместо META-KEY-NAME нужно указать ключи удаляемых плагинов. Их можно найти в таблицах БД.
Удалить все ревизии
Ревизии в Вордпресс очень полезная функция. Но если авторы активно ей пользуются, в БД сохраняется очень много копий постов, которые хранятся и после его публикации.
Удалить разом все ревизии можно таким запросом:
Удалить все комментарии со спамом
Иногда комментариев со спамом становится столько, что вручную их удалить уже не удаётся. С помощью одного SQL-запроса можно удалить сразу все комментарии помеченные как «Спам».
Удалить все неподтвержденные комментарии
Если не хочется удалять вручную все неподтвержденные комментарии, их можно как и спам удалить одним запросом.
Удалить все неиспользуемые теги
Удалить все теги, которые не связаны ни с одним постом можно следующим запросом:
Удалить старые шорткоды
Часто после удаления плагинов в базе остаются нерабочие шорткоды, которые приходится удалять вручную. Это тоже можно сделать одним SQL-запросом.
Где YOUR-SHORTCODE — удаляемый шорткод.
Удалить пингбеки и трекбеки
Интересно, кто-нибудь вообще ими пользуется?
Перед запуском убедитесь, что вы их отключили в админке.
Удалить временные опции
Временные опции в Вордпресс позволяют кешировать часть данных в БД. Но иногда этот кеш тоже может сильно раздуться. Очистить его можно одним запросом.
Оптимизировать таблицы
Раз уж мы зашли в phpMyAdmin, можно заодно проверить и оптимизировать таблицы. Делается это очень просто.
Выбираем все таблицы и нажимаем «Optimize table»
Оптимизация базы данных Вордпресс с помощью плагинов
Для Вордпресс существует ряд плагинов, с помощью которых можно почистить и оптимизировать базу данных. Самые эффективные из них: WP-Optimize и WP-Sweep.
WP-Optimize
Самый популярный плагин для оптимизации баз данных Вордпресс с более чем 600 тыс. активных установок. Очень прост в использовании, управляется одной кнопкой.
В разделе «Table Information» выводится информация по текущим размерам таблиц базы данных и объем, который плагин сможет освободить. В «Настройках» можно запланировать автоматическую оптимизацию БД. Например, каждую неделю, две недели или месяц.
Плагин WP-Optimize очень прост в использовании. Главное, не забудьте перед его использованием создать резервную копию сайта или хотя бы БД.
WP-Sweep
Набирающий обороты плагин от Лестера Чена — известного разработчика Вордпресс.
Плагин имеет интуитивно понятный интерфейс, сразу выводится подробный отчет о том, сколько ненужных данных содержится в базе данных. Можно сразу запустить полную оптимизацию, можно поэтапную.
В отличие от WP-Optimize, WP-Sweet для удаления использует функции Вордпресс, а не прямые запросы к базе данных. Это снижает вероятность пропуска каких-то ненужных данных. Однако, в WP-Sweep пока нет никакой автоматизации процессов.
В заключение
Я надеюсь, эта статья поможет вам оптимизировать и ускорить работу базы данных вашего сайта. Не забывайте перед внесением изменений в базу данных, всегда делать резервную копию сайта.
⚡️ Подписывайся на мой канал @DanilinBiz и ты узнаешь, почему фриланс это свобода, а работа в штате рабство.
Делаю сайты на Вордпресс с 2008 года, в том числе уникальные инструменты для решения сложных бизнес‑задач.
Я работал в офисе с 2003 по 2009 и первые два года в типичной совковой конторе с восьми до пяти, соответствующим контингентом, трудившимся там по тридцать, сорок и более лет. Депрессивная атмосфера не особо вдохновляла на…
Поймав волну своей максимальной продуктивности и настроившись на нее, вполне реально начать жить нормальной жизнью, отвлекаясь на работу на несколько часов в день, а не наоборот. И это не какая-то инфоцыганская мечта, а…
Не каждый работник и работодатель готовы к свободным трудовым отношениям. Вдруг кто-то меня услышит, задумается и осознает, что жизнь одна и просидеть ее в чужом офисе, зарабатывая левому дяде деньги, такая себе…
Использовать разные рабовладельческие 5/2, 2/2 и прочие противоречит моему пониманию концепции фриланса. Мне кажется, у каждого свой баланс, который держит в форме. Надо просто найти его и научиться…
Если человек не ценит твое время, начинает общение с выплескивания тонны ненужной информации, выводит на долгие пустые разговоры, при этом совершенно тебя не слыша — хорошего не жди. Я понимаю, люди бывают разные, но иногда…
Знаю фрилансеров, которые чуть ли не круглые сутки проводят за компьютером. Мне кажется, их продуктивность такая себе и профит подозреваю тоже. Я, например, если сегодня весь день кодил, завтра вряд ли вообще подойду к…
Поработав в штате, начинаешь понимать, что работодателю на тебя плевать. Цель эффективного менеджера выжать из сотрудника максимум, а заплатить минимум. Любой фрилансер, наоборот, стремится работать меньше, а зарабатывать…
Для меня любая нерешенная задача это психологический груз. Их количество растет как снежный ком и в какой-то момент он может просто накрыть. Придется несколько дней безвылазно сидеть за компьютером и все это…
Я пробовал разные форматы и понял, что мне комфортнее не отключаться совсем. Большие задачи разбиваются на более мелкие и последовательно в спокойном ритме решаются. Каждый день небольшими шагами идешь к…
Мне потребовались годы, чтобы понять смысл free в слове фриланс и осознать, что это все не про работу, а больше про образ жизни. Фриланс дает возможность самостоятельно выстроить и адаптировать под себя все рабочие…
Собственные проекты сложны тем, что ты заказчик и исполнитель в одном лице. На ходу корректируешь задачи, уходя в бесконечные правки. Что делаешь реальному заказчику, например, неделю, себе можешь пилить…
У меня в приоритете сайты, которые на моей техподдержке. Если на них что-то случается, я бросаю все и занимаюсь проблемой. Дальше идут заказчики, с которыми я сотрудничаю много лет. Это самые важные в моей работе…
Как очистить таблицы wp_commentmeta и wp_postmeta?
Если вы используете WordPress и некоторое время ведете блог, скорее всего, ваши таблицы wp_commentmeta и wp_postmeta огромны и значительно больше, чем реальные таблицы wp_comments и wp_posts. Да, не имеет смысла, что метаданные, связанные с комментариями и публикациями (фактический контент), намного больше, чем сам контент. В этом посте я покажу, как очистить таблицы wp_commentmeta и wp_postmeta, чтобы значительно уменьшить размер вашей базы данных WordPress, что я недавно узнал. [ Читать: 5 ошибок в блогах, которые я сделал, когда начал этот блог ].
Проблема с wp_commentmeta и wp_postmeta
Посмотрите на этот пример. В одном из блогов, который регулярно оптимизировался с помощью WP-Optimize, но никогда не очищался вручную, ниже приведены размеры таблиц комментариев и сообщений:
- wp_comments – 800 строк и 390,8 КиБ
- wp_commentmeta – 5 387 строк и 6,0 МиБ
- wp_posts – 1300 строк и 3,7 МиБ
- wp_postmeta – 11 947 строк и 3,5 Mib
Почему таблицы метаданных комментариев и сообщений больше, чем сами комментарии и сообщения? Это связано с тем, что таблицы wp_commentmeta и wp_postmeta могут быть быстро заполнены ненужными или устаревшими данными, такими как валидации Akismet и метаданные удаленных постов и ревизий. Итак, давайте посмотрим, как быстро очистить wp_commentmeta и wp_postmeta и оптимизировать их для очистки базы данных.
Меры предосторожности – Резервные таблицы
Поймите, что мы напрямую связываемся с базой данных WordPress, и ошибки могут сделать ваш сайт недоступным. Поэтому всегда лучше сделать резервную копию вашей базы данных. Я собираюсь показать, как легко это сделать из phpMyAdmin. [ Читать: Автоматическое резервное копирование базы данных MySQL на хостинге GoDaddy ].
Войдите в свой интерфейс phpMyAdmin и щелкните мета-таблицу wp_comments. Затем, как показано на рисунке ниже, в разделе «Операции-> Копировать таблицу в» введите имя для резервной копии таблицы. В этом случае я выбрал wp_commentmeta_bk. Затем нажмите «Перейти».
WordPress wp_commentmeta Резервное копирование таблиц
Теперь у вас должна быть новая таблица с именем wp_commentmeta_bk. Повторите те же настройки для таблицы wp_postmeta. Вы можете ввести «wp_postmeta_bk» в качестве имени для резервного копирования или выбрать собственное имя. Кроме того, вы можете экспортировать всю базу данных в виде файла и сохранить его на своем компьютере.
Очистить таблицы wp_commentmeta и wp_postmeta
Очистка wp_commentmeta
Сначала давайте очистим таблицу wp_commentmeta. Как показано на рисунке ниже, нажмите на название вашей базы данных слева и перейдите на вкладку SQL.
SQL-запрос для очистки wp_commentmeta
В текстовом поле и как показано выше введите SQL-запрос, приведенный ниже. Убедитесь, что точка с запятой выбрана в качестве разделителя, и нажмите «Перейти».
Есть 4 отдельных запроса SQL, которые выполняются последовательно. Сначала мы выбираем данные комментариев для несуществующих комментариев (спам или удаленные комментарии), а затем удаляем их. Затем мы выбираем данные комментариев, которые являются проверками Akismet, а затем удаляем их. При успешном выполнении вы должны увидеть «Ваш SQL-запрос был успешно выполнен». Вы также должны увидеть, сколько строк было затронуто.
Рекомендуемые руководства:
Очистка таблицы wp_postmeta
Чтобы очистить таблицу wp_postmeta, снова щелкните по имени базы данных слева и перейдите на вкладку SQL. Введите следующий SQL-запрос в текстовое поле, убедитесь, что точка с запятой отображается в качестве разделителя, и нажмите «Перейти».
Здесь мы также сначала выбираем данные постметы для постов, которые больше не существуют, а затем удаляем их. После выполнения вы должны увидеть сообщение об успешном выполнении и количество затронутых строк.
Оптимизировать таблицы wp_commentmeta и wp_postmeta
Мы очистили мета-таблицы wp_commentmeta и wp_post, но не совсем. Чистые строки будут находиться в таблице как «накладные расходы». Вам придется оптимизировать таблицу, чтобы избавиться от них. К счастью, phpMyAdmin позволяет очень легко выполнять задачи MySQL. [ Read: 10 простых PHPMYADMIN твики для упрощения администрирования MySQL ].
Чтобы оптимизировать таблицу wp_commentmeta, щелкните по названию таблицы слева и перейдите на вкладку «Операции». В разделе «Обслуживание таблиц» нажмите «Оптимизировать таблицу». Повторите шаги для оптимизации таблицы wp_postmeta. Кроме того, вы можете проверить все таблицы и в раскрывающемся меню «С выбранными» выбрать «Оптимизировать таблицу». Теперь вернитесь к представлению структуры базы данных в phpMyAdmin и сравните количество строк и размер таблиц wp_commentmeta и wp_postmeta.
Таблицы WordPress wp_commentmeta и wp_postmeta после очистки
Обратите внимание, что таблица wp_commentmeta уменьшилась с 6,0 МБ до 55,8 КБ (5 387 строк до 592 строк). Это большое сокращение / экономия. Wp_postmeta также показал уменьшение размера. После тщательного тестирования и проверки того, что вы не сломали свою базу данных и не потеряли какие-либо данные, вы можете удалить созданные вами резервные копии таблиц wp_commentmeta и wp_postmeta.
На форуме WordPress есть несколько постов, в которых спрашивается, как очистить wp_commentmeta и wp_postmeta, и, надеюсь, этот пост поможет другим, у кого возникли проблемы. Итак, вы можете оптимизировать таблицы wp_commentmeta и wp_postmeta и очистить базу данных, чтобы улучшить производительность WordPress.
Очистка meta-ключей из таблицы Postmeta
Каждый раз при редактировании поста Вордпресс записывает в базу данных дату и время последнего редактирования записи, старые адреса ссылок и прочую ненужную информацию — все это несомненно загромождает базу данных и замедляет работу. Чтобы навести порядок во всем этом, не потребуется особых знаний и умений, достаточно всего лишь выполнить вот такой SQL запрос к базе данных WordPress в панели PhpMyAdmin:
DELETE FROM `wp_postmeta`
WHERE `meta_key` IN(‘_edit_lock’, ‘_edit_last’,’_wp_old_slug’)
Сделали бэкап базы данных? Отлично! Тогда можно приступать. Выполняя данный запрос, мы удаляем из таблицы wp_postmeta следующие ключи:
_edit_lock Оказывается, если для пользователей открыт доступ для написания постов на Вашем блоге, т.е. в консоли управления на вкладке «Параметры» в пункте «Общие» роль нового пользователя будет обозначена как Автор, то данный параметр будет отвечать за время, в течение которого он может изменять свое сообщение. Число 60 говорит о том, что у пользователя есть 60 минут на редактирование своего сообщения с момента публикации. Данный параметр я считаю абсолютно бесполезным в том случае, если владелец сайта является единственным автором статей.
_edit_last Данный параметр содержит информацию о времени последнего редактирования записи. Не несет в себе существенной смысловой нагрузки и его можно смело удалять.
_wp_old_slug Параметр содержит информацию о предыдущем адресе поста, если были изменения. WordPress хранит в базе данных старые адреса страниц и при их смене производит редирект на новый адрес, отдавая код 200 — как будто страница по-прежнему существует. Это может быть полезным, чтобы не потерять старые ссылки — но может и создавать проблемы, например, поисковики могут обнарудить одинаковое содержимое на «старой» и «новой» странице — а они такое не любят.
Любителям быстрой езды можно выполнить более широкий запрос:
DELETE FROM `wp_postmeta`
WHERE `meta_key` IN(‘_edit_lock’, ‘_edit_last’,’_wp_old_slug’,’_wp_attachment_metadata’)
_wp_attachment_metadata — это метаданные к загруженным картинкам. Среди прочего в них содержатся отсылки к сгенерированным тумбнайлам, что нужно для работы интерфейса медиабиблиотеки. Но на работу самого сайта отсутствие метаданных никак не повлияет — он только быстрее работать станет.
При необходимости метаданные можно пересоздать при помощи какого-нибудь плагина вроде Regenerate Tumbnail — в том числе пересоздать выборочно только для тех картинок, что вам нужны.
На самом деле предлагаемый скрипт можно использовать куда шире — вам лишь нужно найти, какие именно записи в таблице wp_postmeta являются мусорными и вам больше не нужны. Делается это вот так:
Собственно, идея очевидна — в PhpMyAdmin выбираете базу вордпресса, в ней таблицу wp_postmeta, и там для поля meta_key давите кнопочку «Обзор уникальных значений». У вас получится список этих самых уникальных ключей. Ну и вот смотрите на них и думайте — что это и зачем оно вам нужно.
Вот вам пара примеров, как можно организовать чистку мета-ключей:
DELETE FROM `wp_postmeta`
WHERE `meta_value` LIKE ‘_wpAjax%’
DELETE FROM `wp_postmeta`
WHERE `meta_key` LIKE ‘_nxs_snap%’
Конструкция LIKE используется для поиска вхождения в строке по шаблону:
‘abc%’ Любые строки, которые начинаются с букв «abc»
‘abc_’ Строки длиной строго 4 символа, причем первыми символами строки должны быть «abc»
‘%z’ Любая последовательность символов, которая обязательно заканчивается символом «z»
‘%Rostov%’ Любая последовательность символов, содержащая слово «Rostov» в любой позиции строки
‘% % %’ Текст, содержащий не менее 2-х пробелов, например, «World Wide Web»
Как видите, всё просто.
А вот такой запрос позволит вам удалить из wp_postmeta записи, не связанные ни с каким постом (ситуация встречается, когда посты удалили — а постмета к ним осталась):
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL
Ну и для интересующихся — с уровня админа можно выполнить SQL прямо из Вордпресса через PHP вот так:
Cleanup WordPress wp_postmeta Table
I was looking at all the tables in my WordPress database and noticed that the wp_postmeta table had a lot of old and outdated information. For example, it contained a LOT of entries with meta key set to _wp_attached_file , _wp_attachment_metadata . The _wp_attached_file values are all links to old files that no longer exists in my WordPress gallery.
There are also some other entries from old plugins that seem redundant.
I wanted to know if there is a way for me to clean up the data in the table. I found this article after doing some research. The SQL queries listed on the page do work after I make appropriate changes to the table names.
Here are the original queries:
I did not run the DELETE query on my database. However, running the SELECT query gave me the following result.
After seeing a lot of NULL values, I am guessing the query does select redundant values. Should I run the DELETE query now?
Also, I know just basic SQL so could not understand how the queries work. Could anyone please explain it to me?
1 Answer 1
Yes, you can run the DELETE . Personally, I would create a backup table of the rows that are going to be deleted, and then reference that.
The SELECT uery demonstrates the anti-join pattern
The LEFT JOIN is an outer join; that says return all rows from the table on the left (in this case pm ) along with matching rows from the table on the right ( wp ).
One way to think about what the outer join does is that it says if there are no matching rows in wp , then go ahead and create a dummy row that consists of all NULL values, and return the dummy row.
The trick in this query is the condition in the WHERE clause. Any row from wp that matches is guaranteed to have a non-NULL value for wp.id , because only non-NULL values will satisfy the equality comparison in the ON clause. Any NULL value won’t be matched. (Also, its likely id is a column guaranteed to be non-NULL in the table.)
After the join operation, any resulting rows that have a NULL value for wp.id are the result of dummy rows generated by the outer join. So we know there was no matching row in wp .
Another way to generate an equivalent result is to use a NOT EXISTS (correlated subquery) predicate.
I’d create a backup of the rows to be deleted:
And then I’d reference the backup table in the DELETE , with join that references the primary key of the target table.
Assuming here that id is the PRIMARY KEY in the post_meta table (we would need to check that, not just guess), I’d write first as a SELECT:
to test, and then convert to a delete statement by replacing the SELECT keyword with DELETE keyword
Note that it’s critically important that the * be qualified with the table alias t.* .