Очищаем базу данных MySQL на WordPress

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

Сложно ли очистить MySQL от мусора

Когда в самый первый раз заходишь в phpMyAdmin для работы с базой данных MySQL, обилие непонятных табличных данных вызывает ужас. Я особо никогда не изучал MySQL, но когда постоянно там что-то правишь, постепенно начинаешь понимать её структуру. И оказывается всё не так сложно.

Зачем чистить базу MySQL

База данных MySQL это такая же система захламления, как и реестр в Windows. Те кто обладают Mac-ами часто даже не подозревают насколько им повезло, что в MacOS вместо табличного сохранения данных используется файловое.

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

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

Старые табличные данные иногда при экспорте-импорте могут вызывать ошибки. Кроме того они же могут вызывать проблемы при взаимодействии с другими плагинами.

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

MySQL таблицы в WordPress по умолчанию

Долгое время чистая установка WordPress создавала в MySQL всего 11 таблиц. Затем добавили ещё одну таблицу wp_termmeta.

Начиная с WordPress 4.4 в базе данных создаётся 12 таблиц:

1. wp_commentmeta
2. wp_comments
3. wp_links
4. wp_options
5. wp_postmeta
6. wp_posts
7. wp_terms
8. wp_termmeta
9. wp_term_relationships
10. wp_term_taxonomy
11. wp_usermeta
12. wp_users

Что будем чистить?

Для примера я взял один из самых старых моих сайтов, которому уже стукнуло 8 лет. Я никогда раньше не разбирался с таблицами на этом сайте, потому что чего я только туда за время его работы не устанавливал. Но недавно я переделал сайт и удалил из него всё что не использовалось и понял, что пора и базу данных MySQL тоже почистить.

Только вдумайтесь, 91 таблица (одну успел удалить, перед тем как создал скриншот)! Когда WordPress устанавливает всего 12.

Как понять что удалять, а что нет?

По большинству таблиц можно узнать, удалены ли плагины с WordPress или нет. Рабочие таблицы, особенно если сайт работает давно, занимают определенное место, исчисляемое в Kib или Mib, тоже самое что и Кбайт и Мбайт, только по названию двоичной системы.

Если таблица содержит в колонке Rows значение 0 или в колонке Size значение 1 Kib (1 Кбайт), скорее всего эти таблицы для работы сайта не нужны.

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

В табличном имени используется сокращенный префикс от плагина. Иногда по нему можно понять, какой плагин создал эту таблицу. Если не знаете, что за таблица, то Google в помощь.

Начнем разбираться с моими 91 таблицами. Не буду приводить все что я удаляю, но в качестве примера приведу достаточно. Итак, поехали…

Таблицы относятся к плагину NextGEN Custom Fields Plugin. Уже и не помню когда я его устанавливал и для чего мне понадобились произвольные поля для отдельного плагина. Сам плагин уже как 3 года не обновляется. Удаляем таблицу без сожалений:

Это же остатки от таблиц Body Press. Где-то в далёком 2012 году я его устанавливал, экспериментировал, а потом удалил. Таблицу он за собой оставил. Удаляем и её.

Удаляю таблицы данных для плагина Cimy User Extra Fields:

Сейчас на сайте произвольные поля выводятся без сторонних плагинов. А раньше когда-то пользовался плагинами. Перестал использовать, когда очередной плагин начал выдавать ошибки из-за того, что автор забросил его развитие и давно не обновлял.

Таблица относится к плагину GD Rating System. Его я устанавливал еще в 2009 году. С тех пор этого плагина нет, а «могилка» в табличке осталась. То что данные старые и не используются можно понять, если зайти внутрь таблицы и посмотреть на даты:

Плагин GD Rating System насоздавал мне аж 12 таблиц. Вот зачем ему столько?

Когда-то давно я искал плагин рейтингов и перебирал разные. Остановился на WP-PostRatings, который и использую до сих пор. Вот он создал мне в базе данных всего 1 таблицу:

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

Относится к плагину WangGuard. Сегодня не использую. Тоже насоздавал таблиц, которые я удалил:

Остатки от плагина Simple Ads Manager, который помогал вставлять рекламу на сайте. Сейчас предпочитаю это делать непосредственно в шаблонах сайта.

Остатки от плагина цитат. Удалил.

Также удалил остатки плагина Voting Record, который сам по себе перестал обновляться еще 8 лет назад.

Уничтожаем таблицы оставшиеся от плагина голосований:

Остатки от плагина Cross-Linker. Плагин помогающий внедрять ссылки в контекст сайта. Сегодня предпочитаю делать это либо вручную либо через базу данных MySQL. Иначе это напрасная нагрузка на сайт.

Удалил остатки плагина WP-PageNavi. Опять же сегодня навигация работает без сторонних плагинов.

Избавился от таблицы плагина WP People.

Плагин Authors Page, список авторов WordPress. Тоже не использую.

Таблицы оставшиеся от Simple Anti Bot Registration.

Плагин WP Statistics. Удаляем:

Таблица ещё от одного древнего плагина Spam Karma 2 Blacklist Ban.

Вероятно от плагина Shortcodes Ultimate. Удалил.

Непонятная таблица, похожая на таблицу от плагина WordPress Related Posts, но у него есть другая таблица, которую он использует: wp_wp_rp_tags. Может быть та таблица была старой и автор потом заменил её название. Вообщем, рискнул удалить.

Плагин Email Subscribers & Newsletters также насоздавал кучу таблиц. На том сайте я его уже не использую, потому удалил:

wp_options

Эта таблица, которую создает сам WordPress. С ней надо быть осторожнее и не удалить лишнее. Но некоторые плагины любят занести мусор и в таблицы по умолчанию. Например, плагин Antispam Bee оставил строчку за собой, которую я тоже удалил:

Результаты очистки MySQL

Хаос из 91 таблицы, большая часть которых осталась в наследство от давно удалённых плагинов, превратился в 17 необходимых таблиц на сайте:

Меня самого впечатлило, сколько накопилось мусора за время работы того сайта. Сейчас на нём 27 активных плагинов (не считая те, что были написаны мной и не учитываются в общем списке). При этом им достаточно всего 17 таблиц, 12 из которых были созданы самой WordPress.

Что касается размера базы данных, то она уменьшилась всего на какие-то 500 кб и это совсем не существенный размер. Однако в первую очередь цель была направлена именно на очистку неиспользуемых таблиц, а не на уменьшение объёма базы данных.

Для уменьшения размера базы данных обычно достаточно удалить старые ревизии.

How to Optimize WordPress MySQL Without Plugin

How to Clean Up Your WordPress Database

Optimizing Database on Site

Cleaning Up MySQL

Delete Tables From Database When Deleting Plugin

Кстати, на сайте нет рекламы. У сайта нет цели самоокупаться, но если вам пригодилась информация можете задонатить мне на чашечку кофе в макдаке. Лайкнуть страницу или просто поблагодарить. Карма вам зачтется.

Здравствуйте. Нужен совет по рубрикам. Контент был перенесен с поддомена, с уже прописанными в записях рубриками. Сейчас в самих записях рубрики есть. Они нормально присоединились к пунктам в меню, но в каталоге рубрик не отображаются. Как бы это поправить? Можно их как-то записать в каталог ? Вопрос стал актуальным после некоторых манипуляций с плагинами, когда все рубрики, кроме одной созданной уже после переезда сайта в записях просто пропали. Сейчас все восстановлено, проблема была явно вызвана не новыми плагинами. Как бы их прописать на постоянное место жительство в рубрикатор ? wp_terms — содержит все метки тэгов и рубрик, а wp_termmeta — пустая.

Очень сложно объяснили. Не очевидно, что имеется ввиду, когда вы пишите: «нормально присоединились к пунктам в меню» «Можно их как-то записать в каталог»

Как вы переносили данные?

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

А если переносите только ЧАСТЬ контента, для этого в WordPress имеется встроенные и очень простые и понятные инструменты экспорта/импорта. Находятся они в меню администратора: инструменты (отдельные ссылки импорт и экспорт).

«нормально присоединились к пунктам в меню» «Можно их как-то записать в каталог» — Я написала так, как это выглядело для меня. На самом же деле все оказалось на месте, как и должно было быть, просто почему-то в каталоге рубрик графа «описание» отображала на столько много пустого места, что я прокручивая вниз не дошла до следующей рубрики. Отключив «описание» в опциях настройки экрана страницы каталога рубрик, я увидела абсолютно все рубрики. Скорее всего проблема такого представления «описания» рубрик связана с тем, что я правила шаблон вывода рубрик. Подключила вывод шорткодов (для grid+) и анонсов статей. Вот этот grid, по всей видимости, и пытается загрузиться.