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

Очищаем базу данных 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 таблиц:

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_data wp_cimy_uef_fields wp_cimy_uef_wp_fields

wp_cimy_uef_data

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. Сегодня не использую. Тоже насоздавал таблиц, которые я удалил:

DROP TABLE `wp_wangguardcronjobs`, `wp_wangguardquestions`, `wp_wangguardreportqueue`, `wp_wangguardsignupsstatus`, `wp_wangguarduserstatus`;

table sam_errors

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

Удаляем:

DROP TABLE `wp_sam_ads`, `wp_sam_blocks`, `wp_sam_errors`, `wp_sam_places`, `wp_sam_zones`;

wp_xmasb_quotes

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

wp_voting_record

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

wp_pollsa

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

DROP TABLE `wp_pollsa`, `wp_pollsip`, `wp_pollsq`;

wp_interlinker

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

wp_navigation

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

DROP TABLE `wp_navigation`, `wp_navigation_groups`, `wp_navigation_permalinks`;

wp_people

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

wp_authors / wp_authors_stats

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

wp_sabre_table

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

wp_statpress

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

DROP TABLE `wp_statistics_date`, `wp_statistics_reffered`, `wp_statistics_useronline`, `wp_statistics_visits`;

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 также насоздавал кучу таблиц. На том сайте я его уже не использую, потому удалил:

DROP TABLE `wp_es_deliverreport`, `wp_es_emaillist`, `wp_es_notification`, `wp_es_pluginconfig`, `wp_es_sentdetails`, `wp_es_templatetable`;

wp_options

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

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

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

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

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

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

ploshadka.net

Как создать базу данных MySQL для WordPress

Создание базы данных MySQL является обязательным условием для установки и работы с WordPress, поэтому приступим.

Нам необходимо зайти в админ.панель своего хостинга и выбрать пункт управление базами данных MySQL (или просто базы данных, названия могут отличаться). admin panel timeweb

У моего хостинг провайдера создание базы данных выглядит таким образом :

создание базы данных в таймвеб

Я просто выбираю имя пользователя и пароль и БД создается автоматически со всеми настройками.

Если вы пользуетесь хостингом Бегет то за вас это все сделают автоматически и вам не придется тратить время на создание и настройку БД и WordPressa.

Как создать базу данных MySQL в phpMyAdmin

Если у вас панель управления базами данных phpMyAdmin то для создания БД вам необходимо сделать следующее:

Перейти во вкладку Базы Данных, выбрать имя для своей базы. В пункте Сравнение выбираем кодировку utf8_unicode_ci и жмем Создать.

создание базы в phpMyAdmin

Далее во вкладке Пользователи (Привелегии) нужно создать пользователя для нашей базы.

Жмем кнопку “Добавить пользователя” в открывшемся меню выбираем имя , пароль и устанавливаем ему все права в Глобальных привилегиях — жмем “отметить все”.

пользователи phpmyadmin

Однако, как правило, хостинг уже задает определенные настройки для таблиц самостоятельно (иногда при регистрации сайта на хостинге вам сразу создается таблица, а данные к ней высылаются письмом, в таком случае нужно просто заполнить присланные данные в файл wp-config.php или в окне браузера при установке WordPress)

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

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

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

Теперь имея созданную базу данных, мы можем перейти к пункту установки WordPress и наконец приступить к созданию своего сайта.

ruskweb.ru

Ошибки WordPress при работе с MySql — Технический блог

После неудачных экспериментов с базой данных (БД) я получил на блоге следующие ошибки:

Невозможно создать публикацию любого типа (запись, страницу). При этом WordPress выдаёт сообщение: «Вы редактируете страницу, на которой отображаются свежие записи»;
Невозможно добавить комментарий. WordPress сигнализирует об этом так: «Не удалось сохранить комментарий. Пожалуйста, повторите попытку позже».

Манипуляции с установкой/удалением плагинов и тем оформления желаемого результата не принесли. Так же не помогло и обновление самого WordPress. Вывод напрашивался сам собой: проблема кроется в базе данных.

Причина ошибок WordPress и MySQL

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

Ошибка создания новых записей в WordPress

Если у таблицы wp-posts отсутствует автоинкремент, то при попытке создать новую запись вы увидите примерно следующую картину:

Ошибка создания новых записей в WordPress

При этом в таблице wp_posts создаётся запись с нулевым идентификатором и значениями по умолчанию в остальных полях. Статус таких постов — черновик, в списке постов они не отображаются.

Посты с нулевыми идентификаторами можно удалить без каких-либо опасений.

Ошибка добавления комментариев в WordPress

Если у таблицы wp-comments отсутствует автоинкремент, то при попытке создать комментарий вы как администратор получите следующее уведомление:

wordpress-mysql-error_1

Либо, если комментарий оставляет обычный пользователей, то сообщение может быть несколько иным:

wordpress-mysql-error_2

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

Как исправить ошибку MySQL отсутствие автоинкремента

Для выполнения процедуры лечения воспользуемся популярной утилитой phpmyadmin, которая у большинства хостингов доступна по адресу http://mydomain.tld/phpmyadmin. Где mydomain.tld — адрес вашего сайта. Для доступа к базе данных вам необходимы имя пользователя базы данных и его пароль доступа.

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

Проверка таблиц базы данных

Для проверки корректности таблиц воспользуемся командой DESCRIBE:Например проверим таблицу wp_comments командой:

DESCRIBE wp_comments;

wordpress-mysql-error_3

И в результате ее работы получим следующую информацию (пример для исправной таблицы):

wordpress-mysql-error_4

Если у вас в колонке Extra отсутствует значение auto_increment для поля comment_ID, то необходимо выполнить следующую команду:

ALTER TABLE wp_comments CHANGE comment_ID `comment_ID` bigint(20) unsigned NOT AUTO_INCREMENT;

wordpress-mysql-error_5

Если отсутствует Перви́чный ключ PRI, то необходимо выполнить следующее:

ALTER TABLE wp_comments CHANGE comment_ID `comment_ID` bigint(20) unsigned NOT PRIMARY KEY;

Если отсутствуют оба значения, то воспользуйтесь командой ниже:

ALTER TABLE wp_comments CHANGE comment_ID `comment_ID` bigint(20) unsigned NOT AUTO_INCREMENT PRIMARY KEY;

Похожие действия по диагностике и лечению нужно провести для таблиц wp_posts (поле ID), wp_users (поле ID), wp_postmeta, wp_usermeta и wp_commentmeta (поле meta_id).

Удаление записей с нулевым идентификатором

Для таблицы wp_posts делаем так:

DELETE FROM wp_posts WHERE ID = 0;

Аналогично для комментариев:

DELETE FROM wp_comments WHERE comment_ID = 0;

Если постов и комментариев с нулевым идентификатором не много, то их можно удалить вручную в phpmyadmin.

Список использованных источников

При написании статьи были использованы следующие ресурсы:

http://got-quadrat.ru/blog/vosstanovlenie-klyuchej-v-tablitsah-wordpress/

Поделись этой страницей с друзьями!

moonback.ru

Похоже, в вашей конфигурации PHP отсутствует расширение MySQL, необходимое для работы WordPress.

Что делать, когда сервер настроен, база данных работает, но при открытии сайта WordPress появляется сообщение «Похоже, в вашей конфигурации PHP отсутствует расширение MySQL, необходимое для работы WordPress.»

Чаще всего такая проблема возникает при загрузки старой версии WordPress на сервер с PHP7, в котором отсутствует расширение для доступа к базе данных mysql, а вместо него используется mysqli.

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

Вкратце, идея состоит в том, чтобы WordPress загружал нужное расширение. Для этого откройте файл includes/load.php и найдите следующую строчку:

if ( ! extension_loaded( 'mysql' ) && ! extension_loaded( 'mysqli' ) && ! file_exists( WP_CONTENT_DIR . '/db.php' ) ) {

Удалите проверку на загрузку расширения mysql, чтобы получилось следующее:

if ( ! extension_loaded( 'mysqli' ) && ! file_exists( WP_CONTENT_DIR . '/db.php' ) ) {

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

Для обновления WordPress вручную выполните следующие действия:

Удалите на вашем сайте папки wp-admin и wp-includes.
Скачайте последнюю версию системы с сайта WordPress.
Загрузите папки wp-admin и wp-includes из дистрибутива на сервер.
Загрузите папку wp-content на сервер с заменой файлов на новые. Не удаляйте папку wp-content с вашего сайта!
Загрузите все файлы из корня дистрибутива на сервер с заменой.
Зайдите на страницу /wp-admin вашего сайта, чтобы обновить структуру базы данных.

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