Как почистить базу данных mysql

MySQL очистка базы данных.

Как писал недавно, необходимо было поставить трекер на сервак, что прошло без проблем, но вылезла новая проблема, оказывается из-за неправильно настроенной функции на портале, для которого это все было задумано, раздачи не раздавались с него, что опечалило меня и мое начальство ))))
Не вешать нос… Пообщавшись с техподдержкой, были выяснены причины, и мне было дано очередное задание, грохнуть базу данных трекера нах ((( чтоже, ничего не поделаешь, надо значит надо.
Зная что функции очищающей базу данных нет, пришлось все делать ручками, так как время поджимало, а писать скрипт было некогда. В общем начнем, сначала надо залогиниться под своим пользователем БД в мускуле:

ввели свой чудо пароль, и увидели нечто подобное:

если да, то значит все в полном порядке и можно продолжать далее.
Выберем нашу базу:

и просмотрим список ее таблиц:

у меня было нечто такое:

сел прикинул, что влом для каждой таблицы прописывать drop table, и решил на авось затестить скопом удалить таблицы в одной команде:

и чесслово был приятно удивлен, т.к. не думал что все пройдет ок:

для большей уверенности проверил точно ли таблицы удалились:

оказалось что да.
Можно было сделать проще, удалить нахер базу данных, например так:

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

Как очистить MySQL через phpMyAdmin

Если вам свойственно экспериментировать, вы находитесь в постоянном творческом поиске, то не стоит раз от раза запускать сайт с нуля. Задумайтесь, зачем удалять «бывшую в употреблении» базу данных (БД), если придётся создавать новую для очередного детища?

Кому нужен «низкий старт», если достаточно очистить имеющуюся БД от содержимого, и воспользоваться уже известными данными аутентификации на сервере. Минутное дело, если под рукой есть инструмент под названием phpMyAdmin.

PhpMyAdmin— веб-интерфейс для доступа к удалённому MySQL . Представляет собой полноценный инструмент для управления базой данных: экспорт, импорт, прямое редактирование и т. д.

Откройте в “phpMyAdmin” интересующую БД (доступ можно получить из панели управления вашего хостинг-провайдера). В окне появится список всех таблиц в базе, созданных в ходе работы над сайтом. Ниже, щёлкните пункт «Отметить всё», а после справа выберите из выпадающего меню (С отмеченными) — пункт «Удалить». Может потребоваться подтвердить совершаемое действие.

Всё, база данных девственно чиста. Теперь её можно использовать для очередного эксперимента. А как вам удалось оптимизировать рабочие процессы, делитесь в комментариях ниже.

Очистка базы MySQL от мусорных файлов WordPress

Работа с сайтами WordPressСвой сайт от А до ЯУчебник по WordPress

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

Быстродействие сайта — важный параметр, которые оценивается пользователями и поисковыми системами. Если страница долго не загружается, то рядовой посетитель просто закрывает её и переходит на другой сайт. С точки зрения поисковых систем, медленные сайты получают более низкие позиции в выдаче, что постепенно приводит к уменьшению естественного трафика и гибели проекта.

В этой статье мы объясним, как избавить базу MySQL сайта от «мусорных» записей, а также расскажем, насколько регулярно это следует делать и как это можно автоматизировать.

Почему нужна периодическая чистка базы?

Для понимания важности периодической чистки базы веб-проекта достаточно знать, что абсолютно вся информация вашего сайта хранится в ней. Речь идёт о всех публикациях, включая черновые; комментариях, которые оставляют пользователи, а также о другой технической информации.

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

Чтобы наглядно представлять масштаб проблемы, рассмотрим типичный проект, в котором уже накопилось 1500 публикаций, а также в среднем по 10 комментариев к каждой из них. Таким образом, чтобы отразить нужную страницу, необходимо «прошерстить» все 1500 записей и перебрать в общей сложности 15000 комментариев.

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

Именно избавление от этого «довеска» и является основной задачей чистки базы данных. Далее в статье мы поговорим об основных приёмах, как это можно сделать.

Что удалять из БД?

Среди всех разновидностей записей в БД есть несколько основных, вклад которых в «загрязнение» является особенно ощутимым. К ним относятся:

• старые версии публикаций;
• комментарии, помеченные как «спам»;
• содержимое «корзины»;
• данные, оставшиеся удалённых плагинов.

Как раз про удаление и оптимизацию размера этих категорий лишней информации пойдёт мы расскажем более подробно.

Ручная и автоматическая чистка базы сайта

Чтобы почистить БД от лишних записей, можно пойти 2 путями. Первый из них следует отнести к ручным. Заключается он в самостоятельном формировании SQL-запросов, каждый из которых убирает тот или иной тип записей. Из-за необходимости хорошо знать язык таких запросов, ручное вмешательство в БД может быть рекомендовано только продвинутым пользователям и профессионалам.

Для рядовых администраторов сайта на WordPress проще всего воспользоваться автоматическим режимом, то есть выбрать и установить специальный плагин. В большинстве случаев после этого достаточно найти нужный пункт в меню и нажать на кнопку удаления (Delete).

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

Резервное копирование БД

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

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

Если все запланированные операции пройдут успешно, можете повторить их на «боевой» версии БД. В любом случае у вас будет актуальный бэкап, с помощью которого можно откатить все изменения и вернуться к исходному состоянию.

Для экспорта и восстановления баз данных удобно пользоваться phpMyAdmin. Также периодическое создание резервных копий можно настроить через плагины.

Чистим MySQL-базу в ручном режиме

Чтобы произвести чистку базы в ручном режиме, нам понадобиться приложение phpMyAdmin. Оно представляет собой веб-интерфейс, с помощью которого очень удобно администрировать БД проекта.

Перед началом чистки следует чётко понимать, в каких таблицах хранится лишняя информация, а также к какому типу она относится. Также обратите внимание на столбец Overhead в списке таблиц. Его содержимое отражает количество служебной информации, которая содержится в каждой конкретной таблице. Значения здесь редко достигают 0, но очень большие числа в этой колонке дают основание полагать, что чистка всё же требуется.

Чаще всего SQL-запросы составляются, чтобы удалить:

• предыдущие версии записей — post_type = ‘revision’;
• спамные комментарии — comment_approved = ‘spam’; .

Для удаления этих и других записей используется стандартная команда DELETE. После ввода сформированного запроса к БД, его выполнение следует подтвердить.

Внимательно проверьте запросы, которые отправляете на исполнение. Есть риск вместе ненужной информацией потерять нужную.

После завершения удаления вы получите сообщение, в котором будет указано количество записей, попавших под установленные условия.

Автоматическая чистка базы с использованием плагинов

Рассмотрим автоматическую читку базы сайта на примере использования плагина WP Clean Up. Установите и активируйте его привычным способом перед началом использования.

В настройках модуля вы обнаружите простую таблицу, в которой перечислены основные типы «мусорной» информации, а также счётчик таких записей. Чтобы избавиться от них, достаточно нажимать на кнопку Delete, расположенную напротив. Альтернативным вариантом быстрой чистки является использование кнопки Delete All.

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

Аналогичные функции выполняют и другие плагины. Вот только самые известные и популярные из них:

• WP-DBManager;
• WP-Optimize;
• WP Clean Up Optimizer;
• WPDBSpringClean.

WP-DBManager — мощный плагин для профессионального использования. Его функционал частично повторяет phpMyAdmin, но в отличие от последнего приложения, позволяет выполнять большинство действий с базой прямо из административной консоли. Популярность плагина объясняется встроенным механизмом резервного копирования и восстановления. Запасные копии можно хранить на самом сервере или отправлять их себе по email. Для экономии места их размер легко уменьшить с помощью сжатия. Также модуль умеет восстанавливать базы и предлагает пользователю возможности по выполнению SQL-запросов и управлению таблицами. Ограничением плагина является то, что он не предназначен для читки абсолютно всего «мусора» в базе, а направлен в большей степени на служебные данные.

Модуль работает на WordPress старше 4 версии и получает регулярные обновления. По результатам 100 тыс. установок пользователи оценили его на 4,4 балла.

WP-Optimize — простой интерфейс и многофункциональность сделали этот плагин для оптимизации БД одним из самых популярных среди аналогов. Пользователи, которые скачали его уже более 1 млн. раз поставили ему среднюю оценку 4,8 балла.

Большую часть «мусорной» информации здесь можно удалить одной кнопкой. Чтобы не возвращаться к очистке каждый раз, можно запланировать её регулярное выполнение. Также модуль наглядно показывает информацию по таблицам и умеет считать сколько памяти получится освободить в результате оптимизации.

Плагин совместим с версиями WordPress от 4.4 до 5.6.1 и умеет выполнять другие действия по оптимизации производительности сайта, например, сжимать картинки.

Встроенного инструмента создания бэкапов здесь не предусмотрено, но их можно создавать с помощью сторонних модулей.

WP Clean Up Optimizer — этот плагин появился относительно недавно и ещё не успел набрать большую пользовательскую базу. Всего его скачали 5 тыс. раз и оценили на 4,1 балла.

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

WPDBSpringClean — плагин специально предназначен для поиска и удаления в базе данных таблиц, которые остались от других плагинов. Необходимость его создания была продиктована тем фактом, что большинство из сторонних модулей даже после удаления продолжают хранить на сайте свои данные. WPDBSpringClean позволяет находить пустые таблицы с заданными параметрами. Пользуйтесь им с осторожностью, чтобы случайно не удалить ценную информацию. За несколько лет существования модуль успели скачать около 2 тыс. раз и оценили его 4,5 баллов.

Регулярность чистки базы

Начинающие пользователи часто задаются вопросом о том, насколько часто нужно чистить базу? Однозначного ответа на него нет. Всё зависит от посещаемости самого проекта, а также периодичности появления новых публикаций. Чем чаще на сайте появляются новые статьи, чем больше комментариев они собирают, тем чаще необходимо производить чистку. Например, нагруженные проекты можно профилактически чистить хоть каждый день. В свою очередь сайты с несколькими новыми статьями в месяц могут длительное время обойтись и вовсе без чистки, особенно если правильно настроить их параметры.

Профилактика загрязнения БД

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

Например, можно ограничить количество сохраняемых версии публикаций до 3 или сократить количество дней до автоматической очистки «корзины», установив значение 5. Для этого необходимо внести небольшие правки в файле wp-config.php. Здесь нас интересуют строки, в которых есть следующие ключевые слова: WP_POST_REVISIONS и EMPTY_TRASH_DAYS. Задайте для них свои значения и наслаждайтесь высоким быстродействием базы длительное время. Без этих настроек WordPress продолжал бы хранить все старые версии статей, а также удерживал содержимое «Корзины» в течение месяца.

Для борьбы с комментариями, содержащими спам, используйте модуль Akismet. Его преимуществом является возможность задать более короткий промежуток времени для избавления от этого «мусора». По умолчанию, WordPress не удаляет спам целых 30 дней.

Заключение

Удаление «мусора» из базы данных сайта позволяет поддерживать её производительность на приличном уровне. Чисткой необходимо заниматься с периодичностью, которая определяется масштабом проекта. Чистить и оптимизировать БД можно как в ручном, так и автоматическом режиме. Очень удобно пользоваться для этого специальными плагинами. Результатом чистки является уменьшение размера базы. В итоге на выполнение запросов данных из неё уходит меньше времени, а сайт работает быстрее.

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

Admin 06.10.2017 , обновлено: 01.03.2018 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 таблицами. Не буду приводить все что я удаляю, но в качестве примера приведу достаточно. Итак, поехали…

Таблица wp_nggcf_fields

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

wp_bp

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

wp_cimy

Удаляю таблицы данных для плагина Cimy User Extra 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 кб и это совсем не существенный размер. Однако в первую очередь цель была направлена именно на очистку неиспользуемых таблиц, а не на уменьшение объёма базы данных.

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

English Query (запросы по теме на английском языке)

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

Читайте также

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

Комментарии к статье “ Очищаем базу данных MySQL на WordPress ” (3)

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

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

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

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

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

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