База данных на одном из сайтов стала слишком сложной для восприятия. Пришло время её чистки. Ниже о том, как понять, какую таблицу можно удалять в WordPress, а какую нет.
Сложно ли очистить MySQL от мусора
Когда в самый первый раз заходишь в phpMyAdmin для работы с базой данных MySQL, обилие непонятных табличных данных вызывает ужас. Я особо никогда не изучал MySQL, но когда постоянно там что-то правишь, постепенно начинаешь понимать её структуру. И оказывается всё не так сложно.
Зачем чистить базу MySQL
База данных MySQL это такая же система захламления, как и реестр в Windows. Те кто обладают Mac-ами часто даже не подозревают насколько им повезло, что в MacOS вместо табличного сохранения данных используется файловое.
В базу данных MySQL записывается разного рода информация, в том числе от установленных на сайт плагинов. Иногда в поисках нужного плагина приходится устанавливать много других. Потом эти плагины удаляешь, а они свои данные оставляют в MySQL. Так постепенно база данных захламляется ненужного рода информацией.
Это приводит к тому, что база данных содержит много неиспользуемых таблиц. Они чисто визуально вносят сложность в понимание, что используется на сайте, а что нет. Особенно, если сайтов много и уже не помнишь, какой плагин установлен и для каких целей используется.
Старые табличные данные иногда при экспорте-импорте могут вызывать ошибки. Кроме того они же могут вызывать проблемы при взаимодействии с другими плагинами.
Конечно, можно жить без оптимизации таблиц, часто пустые табличные данные ни на что не влияют, как можно и не убирать пыль под диваном. И пока не загляните, не испугаетесь. Но это уже выбор каждого отдельного человека.
MySQL таблицы в WordPress по умолчанию
Долгое время чистая установка WordPress создавала в MySQL всего 11 таблиц. Затем добавили ещё одну таблицу wp_termmeta.
Начиная с WordPress 4.4 в базе данных создаётся 12 таблиц:
- wp_commentmeta
- wp_comments
- wp_links
- wp_options
- wp_postmeta
- wp_posts
- wp_terms
- wp_termmeta
- wp_term_relationships
- wp_term_taxonomy
- wp_usermeta
- wp_users
Что будем чистить?
Для примера я взял один из самых старых моих сайтов, которому уже стукнуло 8 лет. Я никогда раньше не разбирался с таблицами на этом сайте, потому что чего я только туда за время его работы не устанавливал. Но недавно я переделал сайт и удалил из него всё что не использовалось и понял, что пора и базу данных MySQL тоже почистить.
Только вдумайтесь, 91 таблица (одну успел удалить, перед тем как создал скриншот)! Когда WordPress устанавливает всего 12.
Как понять что удалять, а что нет?
По большинству таблиц можно узнать, удалены ли плагины с WordPress или нет. Рабочие таблицы, особенно если сайт работает давно, занимают определенное место, исчисляемое в Kib или Mib, тоже самое что и Кбайт и Мбайт, только по названию двоичной системы.
Если таблица содержит в колонке Rows значение 0 или в колонке Size значение 1 Kib (1 Кбайт), скорее всего эти таблицы для работы сайта не нужны.
За исключением тех таблиц, которые устанавливаются самим WordPress. Их лучше не трогать, даже если они пустые. Например, мало кто сегодня пользуется отдельным разделом ссылок на сайте, за который отвечает wp_links. В результате таблица пустая, но удалять её нежелательно.
В табличном имени используется сокращенный префикс от плагина. Иногда по нему можно понять, какой плагин создал эту таблицу. Если не знаете, что за таблица, то Google в помощь.
Начнем разбираться с моими 91 таблицами. Не буду приводить все что я удаляю, но в качестве примера приведу достаточно. Итак, поехали…
Таблица wp_nggcf_fields
Таблицы относятся к плагину NextGEN Custom Fields Plugin. Уже и не помню когда я его устанавливал и для чего мне понадобились произвольные поля для отдельного плагина. Сам плагин уже как 3 года не обновляется. Удаляем таблицу без сожалений:
wp_bp
Это же остатки от таблиц Body Press. Где-то в далёком 2012 году я его устанавливал, экспериментировал, а потом удалил. Таблицу он за собой оставил. Удаляем и её.
wp_cimy
Удаляю таблицы данных для плагина Cimy User Extra Fields:
wp_cimy_uef_fields
wp_cimy_uef_wp_fields
Сейчас на сайте произвольные поля выводятся без сторонних плагинов. А раньше когда-то пользовался плагинами. Перестал использовать, когда очередной плагин начал выдавать ошибки из-за того, что автор забросил его развитие и давно не обновлял.
wp_gdsr
Таблица относится к плагину GD Rating System. Его я устанавливал еще в 2009 году. С тех пор этого плагина нет, а «могилка» в табличке осталась. То что данные старые и не используются можно понять, если зайти внутрь таблицы и посмотреть на даты:
Плагин GD Rating System насоздавал мне аж 12 таблиц. Вот зачем ему столько?
Когда-то давно я искал плагин рейтингов и перебирал разные. Остановился на WP-PostRatings, который и использую до сих пор. Вот он создал мне в базе данных всего 1 таблицу:
И почему другие авторы не желают придерживаться такого же минимализма? Или хотя бы убирали за собой.
wp_wangguard
Относится к плагину WangGuard. Сегодня не использую. Тоже насоздавал таблиц, которые я удалил:
table sam_errors
Остатки от плагина Simple Ads Manager, который помогал вставлять рекламу на сайте. Сейчас предпочитаю это делать непосредственно в шаблонах сайта.
Удаляем:
wp_xmasb_quotes
Остатки от плагина цитат. Удалил.
wp_voting_record
Также удалил остатки плагина Voting Record, который сам по себе перестал обновляться еще 8 лет назад.
wp_pollsa
Уничтожаем таблицы оставшиеся от плагина голосований:
wp_interlinker
Остатки от плагина Cross-Linker. Плагин помогающий внедрять ссылки в контекст сайта. Сегодня предпочитаю делать это либо вручную либо через базу данных MySQL. Иначе это напрасная нагрузка на сайт.
wp_navigation
Удалил остатки плагина WP-PageNavi. Опять же сегодня навигация работает без сторонних плагинов.
wp_people
Избавился от таблицы плагина WP People.
wp_authors / wp_authors_stats
Плагин Authors Page, список авторов WordPress. Тоже не использую.
wp_sabre_table
Таблицы оставшиеся от Simple Anti Bot Registration.
wp_statpress
Плагин WP Statistics. Удаляем:
wp_sk2_logs
Таблица ещё от одного древнего плагина Spam Karma 2 Blacklist Ban.
wp_shortcodes
Вероятно от плагина Shortcodes Ultimate. Удалил.
wp_relatedposts
Непонятная таблица, похожая на таблицу от плагина WordPress Related Posts, но у него есть другая таблица, которую он использует: wp_wp_rp_tags. Может быть та таблица была старой и автор потом заменил её название. Вообщем, рискнул удалить.
Таблицы wp_es
Плагин Email Subscribers & Newsletters также насоздавал кучу таблиц. На том сайте я его уже не использую, потому удалил:
wp_options
Эта таблица, которую создает сам WordPress. С ней надо быть осторожнее и не удалить лишнее. Но некоторые плагины любят занести мусор и в таблицы по умолчанию. Например, плагин Antispam Bee оставил строчку за собой, которую я тоже удалил:
Результаты очистки MySQL
Хаос из 91 таблицы, большая часть которых осталась в наследство от давно удалённых плагинов, превратился в 17 необходимых таблиц на сайте:
Меня самого впечатлило, сколько накопилось мусора за время работы того сайта. Сейчас на нём 27 активных плагинов (не считая те, что были написаны мной и не учитываются в общем списке). При этом им достаточно всего 17 таблиц, 12 из которых были созданы самой WordPress.
Что касается размера базы данных, то она уменьшилась всего на какие-то 500 кб и это совсем не существенный размер. Однако в первую очередь цель была направлена именно на очистку неиспользуемых таблиц, а не на уменьшение объёма базы данных.
Для уменьшения размера базы данных обычно достаточно удалить старые ревизии.
Здравствуйте. Нужен совет по рубрикам.
Контент был перенесен с поддомена, с уже прописанными в записях рубриками. Сейчас в самих записях рубрики есть. Они нормально присоединились к пунктам в меню, но в каталоге рубрик не отображаются. Как бы это поправить? Можно их как-то записать в каталог ? Вопрос стал актуальным после некоторых манипуляций с плагинами, когда все рубрики, кроме одной созданной уже после переезда сайта в записях просто пропали.
Сейчас все восстановлено, проблема была явно вызвана не новыми плагинами. Как бы их прописать на постоянное место жительство в рубрикатор ?
wp_terms — содержит все метки тэгов и рубрик, а wp_termmeta — пустая.
Очень сложно объяснили. Не очевидно, что имеется ввиду, когда вы пишите:
«нормально присоединились к пунктам в меню»
«Можно их как-то записать в каталог»
Как вы переносили данные?
Если нужно перенести весь сайт, только тогда имеет смысл переносить через базу данных MySQL. При переносе всей базы данных, ничего в процессе переноса теряться не должно.
А если переносите только ЧАСТЬ контента, для этого в WordPress имеется встроенные и очень простые и понятные инструменты экспорта/импорта. Находятся они в меню администратора: инструменты (отдельные ссылки импорт и экспорт).
«нормально присоединились к пунктам в меню»
«Можно их как-то записать в каталог» — Я написала так, как это выглядело для меня. На самом же деле все оказалось на месте, как и должно было быть, просто почему-то в каталоге рубрик графа «описание» отображала на столько много пустого места, что я прокручивая вниз не дошла до следующей рубрики. Отключив «описание» в опциях настройки экрана страницы каталога рубрик, я увидела абсолютно все рубрики. Скорее всего проблема такого представления «описания» рубрик связана с тем, что я правила шаблон вывода рубрик. Подключила вывод шорткодов (для grid+) и анонсов статей. Вот этот grid, по всей видимости, и пытается загрузиться.