Доброго здоровья всем читателям блога! Сегодняшняя тема очень важна для каждого вебмастера, а посему немедленно даю вам информацию по вопросу оптимизации БД Mysql, которая преследует цель ускорения загрузки страниц блога WordPress. К слову, создание базы данных возможно в административной панели хостинга.
Почему оптимизация так важна? На это есть несколько причин, важнейшие из них две. Во-первых, скорость загрузки вебстраниц сайта влияет на ранжирование ресурса в поисковой выдаче, это ”медицинский” факт. Кстати, одной из составляющих успеха вполне может стать правильно проведенная оптимизация статей блога или сайта WordPress.
Во-вторых, быстро загружаемые страницы задерживают посетителей на сайте, ведь приятно, когда быстро можно переходить из раздела в раздел, не тратя лишних нервов. Поэтому, если даже материал на сайте заслуживает всяческого уважения, но медленно открываются страницы, читатель скорее всего уйдет и поищет более удобный с этой точки зрения ресурс.
Мой блог тоже до сегодняшнего дня не отличался хорошими показателями по скорости загрузки, поэтому я решил исправить ситуацию и провести оптимизацию БД MySql. Этим я и хочу с вами поделиться (к слову, оптимизацию БД можно автоматизировать воспользовавшись расширением WP Optimize). Честно говоря, я пришел в ужас, когда вплотную решил заняться оптимизацией базы данных MySql и увидел ее размер, использовав для этого панель phpMyAdmin:
На самом деле, объем базы данных такого небольшого ресурса, как мой блог, превышающий 30 МБ, катастрофа. Поэтому я решил немедленно уделить процессу оптимизации часть драгоценного времени. Далее представлю вам, уважаемые читатели, подробную инструкцию, что необходимо сделать, чтобы исправить ситуацию. Прежде всего, необходимо войти на страницу phpMyAdmin. Я уже писал, что сделать это можно с панели управления вашим хостингом.
Поищите, там обязательно должна быть ссылка «phpMyAdmin» или что-то в этом роде. Там на левой стороне выбираете базу данных Mysql своего блога, кликнув по ней, в результате чего получите список таблиц этой базы. Теперь внимание! Прежде чем, приступить непосредственно к оптимизации, необходимо сделать резервную копию (бэкап) базы данных, используя соответствующую опцию программы phpMyadmin. Это необходимо для того, чтобы в случае ваших ошибочных действий ее можно было без проблем восстановить.
Действия по оптимизации таблиц Mysql базы данных
Теперь переходим к делу. Прежде всего, необходимо удалить лишние таблицы из базы данных MySql. Как это определить? Дело в том, что когда вы только создаете свой ресурс, то в первичной базе данных Mysql образуются следующие таблицы (по вполне разумному совету Aleksa в комментариях дополню, что префикс по умолчанию WP в целях безопасности может быть изменен, как это сделать, напишу в отдельной статье):
wp_comments wp_links wp_options wp_postmeta wp_posts wp_terms wp_term_relationships wp_term_taxonomy wp_usermeta wp_users
Но при дальнейшем развитии ресурса, например, при установке различных плагинов, образуются новые таблицы. Очень часто случается так, что приходится то или иное расширение (плагин) удалить, например, для замены его соответствующим кодом (опять же для ускорения сайта). В этом случае таблицы, соответствующие удаленному расширению, остаются и лежат мертвым грузом.
Например, у меня был плагин WP-Monalisa, который генерирует смайлики для отражения в комментариях. Но ввиду лишней нагрузки на сервер, создаваемой этим расширением, я его удалил, тем более при сильном желании смайлы можно использовать, вводя код в поле для комментариев. Теперь показываю, как я удалил оставшиеся от него таблицы. Для этого галочкой надо отметить соответствующую строчку и нажать на значок удаления:
Все, лишние таблицы удалены. Теперь приступаем к следующему шагу. Сначала необходимо внести определенные изменения в файл wp-config.php. Обычно он располагается в папке httpdocs или public_html. Для его редактирования лучше всего использовать замечательный редактор notepad++, который позволяет загрузить файлы с хостинга при помощи ftp-соединения и отредактировать. Конечно, можно редактировать прямо через админ панель хостинга, но с недавних пор я пользуюсь именно notepad++. Итак, открываем notepad++ и загружаем файл wp_config на компьютер. Вставляем в файл две следующих строки:
define('WP_POST_REVISIONS', false); define('EMPTY_TRASH_DAYS', 0);
Очень внимательно отнеситесь к операции редактирования файла, чтобы избежать неприятных минут в дальнейшем. Вставьте две вышеупомянутые строчки сюда:
Первая строчка отключает ревизии постов. Что это такое? Допустим, вы написали статью, затем отредактировали ее и не единожды, все эти варианты (ревизии) будут храниться в базе данных, что создает лишнюю нагрузку, поэтому нужно отключить их образование.
Вторая строка лимитирует время хранения файлов в корзине. Здесь можно поставить любые значения вплоть до 0. Но имейте ввиду, что если отметите 0, то это значит, что полностью отключите корзину и все файлы будут удаляться безвозвратно, так что будьте здесь осторожны. Я поставил значение 1, как видите из скриншота. После изменения сохраните файл там же в редакторе notepad++ и нажмите «upload» для загрузки уже отредактированного файла wp_config обратно на хостинг.
Теперь удалим все ранее скопившиеся ревизии. Для этого в админ панели phpMyadmin выберите базу данных и перейдите во вкладку «SQL», где введите следующий запрос:
DELETE FROM wp_posts WHERE post_type = "revision"
Это будет выглядеть следующим образом:
После ввода запроса нажмите кнопку «ОК» в нижнем правом углу. Почти сразу получаете результат, вывод которого занимает доли секунды:
Как видите, удалено более 2000 строк. Далее таблицу wp_post необходимо оптимизировать, вновь используя вкладку «SQL» и введя следующий запрос:
OPTIMIZE TABLE wp_posts;
После этого можно удалить все спам-комментарии на блоге Вордпресс с помощью соответствующего запроса:
DELETE FROM wp_comments WHERE comment_approved = 'spam';
Далее удаляем пингбеки. Это уведомления, которые приходят, когда, например, проставляется ссылка на ваш ресурс с другого сайта или блога, без них в принципе можно обойтись. Вводим такой запрос:
DELETE FROM wp_comments WHERE comment_type = 'pingback';
Теперь вообще отключим запись пингбеков в базу данных Mysql c помощью очередного запроса:
UPDATE wp_posts p SET p.ping_status = 'closed'
Вот и вся работа по оптимизации MySql базы данных. Однако теперь необходимо оценить результат проделанной работы, вот он:
Если вы сравните этот скриншот с тем, который я приводил в начале поста, то увидите, что объем базы данных уменьшился в 10 раз! Конечно, до такого доводить нельзя и действия по очистке базы желательно производить хотя бы раз в месяц. Надеюсь, вы получили стоящую информацию, прочитав статью, если желаете и впредь получать подобные материалы, не забывайте подписываться на обновления блога. На сегодня позвольте откланяться, новые статьи не заставят себя долго ждать.
Aleks, весьма справедливое замечание, однако я исходил из того, что в подавляющем большинстве случаев этот префикс и установлен. Но Вы правы, нужно учитывать все нюансы, спасибо. Дополнение внес, тем более планирую написать статью об изменении префиксов.
Статья то хорошая, но нужно уточнять "wp_posts" - это когда префикс базы данных остается по умолчанию!!! Неплохо бы подкорректировать статью...
Хороший блог с ценным контентом. Пригодится!
Такие несуразности могут возникать, если у Вас не обновлен WordPress. Попробуйте обновиться.
Спасибо за статью. Все сделала, как Вы описали.
Но заметила одну странную особенность. В таблице wp_posts некоторые записи дублируются, а иные и по три раза сохранены. И когда пишу следующую статью, то id увеличивается сразу на два или на три.
Отчего так происходит? И как удалить дублированные посты, чтобы id шел по-порядку, а не через один или два?
Да, Николай, Вы правы, здесь каждый решает сам. Ничего страшного не произойдет, если функция сохранения ревизий останется. Просто я обязан был предоставить читателям все известные мне методы оптимизации.
Спасибо за полезную статью! БД для моего небольшого блога раздулась до 70 мегабайт! В основном это из-за сохранения ревизий.
Очень все подробно и хорошо описали. Единственное, я для себя не убрал функцию сохранения ревизий, так как иногда бывает нужно, если вдруг статью нужно откатить до предудущей версии, меня иногда спасало, если по неосторожности удалял половину текста))
Поэтому, на мой взгляд, проще оставить эту функцию, просто иногда чистить ревизии.
Спасибо!
очень полезно. Помогло колоссально!
Пожалуйста, Даниил. 🙂
Спасибо за ценную информацию!
Пожалуйста, Сергей. Даже не сомневаюсь, что пригодится.
Игорь, спасибо! Блог у меня новый, но на будущее пригодится.
Совершенно верно, Марина, спасибо за дополнение. 🙂
Совсем не обязательно ставить галочку. Можно просто нажать на иконку удаления напротив нужной записи.
Если ставить галочку, то внизу надо выбирать "С выделенными: Удалить"
Я очень рад, David, что информация оказалась Вам полезной. Оптимизация - дело очень важное, хорошо, что Вы это осознаете. Удачи Вашему проекту!
Я Вас переплюнул, у меня "Удалено строк: 4234" :))
Спасибо большое за Вашу статью, работу.
Очень нужная информация, меня сейчас очень серьёзно затронула проблема оптимизации сайта, вовсю над эти работаю, а данная статья внесла большой вклад в это дело.
Естественно, Вы должны использовать тот префикс, который используется в таблицах базы данных Вашего сайта. А то, что у Вас префикс, отличный от wp, очень хорошо для безопасности ресурса.
Максим, именно файлы сайта. Я хочу пояснить Вам, что понятие файлы подходит ко всем операционным системам, а не только Windows.
И ещё забыл спросить - если у меня префикс отличный от wp, то мне писать:
define(‘мойпрефикс_POST_REVISIONS’, false);
?
Плагин WP-Optimize удаляет многое из описанного в данной статье, можно было бы написать об этом.
Речь идёт наверно всё-таки не о файлах, а о материалах. А то пишите "время хранения файлов в корзине", "все файлы будут удаляться безвозвратно" как будто говорим про Windows.
Людмила, то есть у Вас таблицы базы данных такого вида: wscrp_comments, wscrp_posts, wscrp_terms и т.д.?
Скажите, у меня обозначения wscrp вместо wp и такой способ оптимизации не проходит. Подскажите, что делать.
Спасибо за полезную статью, узнал много нового!
Спасибо за пост. Работаю с движков уже довольно долго, проблемы, что яшка под агс запихивает из-за дублей и прочих недочетов.