Оглавление:
Зачем оптимизировать базу данных?
Компактная и оптимизированная база данных сайта на WordPress работает значительно эффективнее громоздкой. Чем меньше объем таблиц, тем быстрее сервер обрабатывает запросы CMS. Это ускоряет загрузку страниц для посетителей и делает работу в админ-панели более отзывчивой при создании или обновлении контента.
Важно понимать, что именно мы оптимизируем. База данных WordPress хранит текстовую информацию: записи, страницы, настройки меню, данные пользователей и комментарии. При этом тяжелые файлы (изображения, аудио, видео) находятся в папке wp-content/uploads, а в базе хранятся только ссылки на них. Поэтому оптимизация БД — это работа со структурой и текстом, а не с весом картинок.
Со временем база данных неизбежно «замусоривается» ненужными записями, что замедляет ее работу. В этой статье мы разберем, как очистить БД от лишнего и вернуть сайту былую скорость.
Что такое «мусорные» данные?
Под «мусором» понимается любая избыточная информация, которая не приносит пользы сайту, но нагружает сервер. К таким данным относятся:
- Ревизии. Самый главный «пожиратель» места. Каждая правка создает полную копию текста. На больших сайтах их могут быть тысячи.
- Спам и очереди модерации. Боты могут генерировать сотни комментариев в день. Это быстро раздувает таблицы wp_comments и wp_commentmeta.
- Осиротевшие связи и метаданные. Самый коварный мусор. Он не виден в админке, но замедляет сложные запросы (например, поиск или фильтрацию).
- Корзина. Занимает место, но WordPress по умолчанию очищает ее каждые 30 дней.
Технический план очистки базы данных
Шаг 1. Настройка окружения
Прежде чем приступать к очистке, необходимо выбрать инструмент для работы с таблицами. Чаще всего это делается двумя способами:
- phpMyAdmin — cамый доступный вариант, который есть в панели управления любого хостинга. Этот скрипт позволяет выполнять SQL-запросы через браузер прямо на стороне сервера. Поскольку для базы данных он является локальным, вам не нужно настраивать удаленный доступ и устанавливать дополнительный софт на свой компьютер.
- Внешние менеджеры баз данных. Десктопный софт вроде HeidiSQL, обеспечивает более высокую скорость и удобство. Однако для их работы на сервере должен быть разрешен удаленный доступ к MySQL. Подключение к базе на локальном сервере, установленном на вашем же компьютере, также считается удаленным!
Демонстрация удаленного подключения к локальной базе данных MySQL в программе HeidiSQL.
Шаг 2. Бэкап!
Обязательно сделайте резервную копию БД! Перед очисткой важно не просто создать дамп, но и убедиться, что он прошел без ошибок. В идеале стоит проверить целостность бэкапа, развернув его на локальном сервере — так вы будете на 100% уверены, что сможете восстановить сайт в случае сбоя.
Шаг 3. Отключаем ревизии постов
При каждом нажатии на кнопки «Сохранить» или «Обновить» WordPress создает в базе данных новую промежуточную версию статьи. Особенно заметно база раздувается при работе над длинными материалами, которые пишутся частями и сохраняются десятки раз.
Представьте, что объем вашей статьи — 50 КБ. Если в процессе работы вы сохранили ее 100 раз, в базе данных накопится уже 5000 КБ (5 МБ) данных. Получается, что 4,5 МБ места потрачено впустую на одну статью. А если таких материалов на сайте сотня? Ваша база данных раздуется на 450 МБ из-за одного только «мусора»!
Каждая ревизия — это не только текст статьи. WordPress создает записи в таблице wp_posts, а к ним подтягиваются строки в wp_postmeta. Если у вас стоят плагины вроде Yoast SEO или Elementor (любые конструкторы повышают ставки в 10 раз), они добавляют кучу своих данных к каждой ревизии.
Помимо ручных сохранений, WordPress сам делает автосохранения каждые 60 секунд. Если автор долго держит вкладку открытой и пишет, база незаметно растет.
Количество ревизий можно регулировать через файл wp-config.php. Одну из этих строк нужно добавить выше фразы /* That’s all, stop editing! Happy publishing. */. Если вставить ниже, настройка может не сработать.
// Оставляем 3 ревизии
define( 'WP_POST_REVISIONS', 3 );
// или
// Отключаем полностью
define( 'WP_POST_REVISIONS', false );
Лично я предпочитаю полное отключение ревизий, а уже созданные копии удаляю из базы вручную.
Отключаем ревизии с помощью моего мини-плагина >>
Теперь очистим базу от уже накопившихся ревизий. Для этого обратимся к таблице wp_posts (префикс wp_ у вас может отличаться). Нам нужно найти столбец post_type и удалить из таблицы все строки, где значение в этом поле равно revision.
Также можно выполнить прямой SQL-запрос к БД:
DELETE FROM wp_posts WHERE post_type = 'revision';
Шаг 4. Избавляемся от лишних комментариев
Если у вашего сайта высокая посещаемость и открыты комментарии, вы неизбежно столкнетесь с огромным количеством спама. Akismet эффективно отфильтровывает такие сообщения, но не удаляет их сразу, помещая в отдельный список. Это значит, что тысячи спам-записей по-прежнему остаются в вашей базе данных! Чтобы они не занимали место, их необходимо регулярно удалять в соответствующем разделе админ-панели.
В WordPress есть скрытая константа для wp-config.php, которая сама чистит спам и корзину через определенное время.
// Автоматическая очистка каждые 7 дней
define( 'EMPTY_TRASH_DAYS', 7 );
SQL-запросы для полной очистки:
-- Удаляем весь спам
DELETE FROM wp_comments WHERE comment_approved = 'spam';
-- Очищаем корзину
DELETE FROM wp_comments WHERE comment_approved = 'trash';
-- Удаляем "осиротевшие" метаданные
DELETE FROM wp_commentmeta WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);
Регулярная оптимизация БД в WP снижает нагрузку на сервер, сокращает время отклика сайта и уменьшает размер резервных копий. Поддерживайте чистоту таблиц wp_posts и wp_comments для стабильной работы проекта.
Встроенные редиректы WordPress — скрытая нагрузка на базу данных
Эта тема часто игнорируется в контексте оптимизации базы данных WP, так как встроенный механизм редиректов часто рассматривается как полезная функция ядра CMS. Он не создает отдельных кастомных таблиц, а тихо раздувает стандартную wp_postmeta изнутри. Поэтому я решил немного обособить эту проблему.
При смене URL или удалении записи WordPress сохраняет старый адрес в таблицу под ключом _wp_old_slug. Если страница меняла свой ярлык множество раз, во внутренних механизмах CMS возникает путаница. Для одного материала формируется целая история из старых адресов. В результате ядро вынуждено последовательно перебирать эти записи в базе данных, выполняя лишние циклы проверок.
Решение этой проблемы категорически простое. Все перенаправления необходимо полностью переносить на уровень сервера, используя файл .htaccess (для Apache) или конфигурационный файл nginx.conf. Серверный редирект срабатывает мгновенно, еще до того, как запустится тяжелый PHP-скрипт WordPress и полетит первый запрос в MySQL.
Вот SQL-запрос для оценки масштаба проблемы (без немедленного удаления записей):
SELECT meta_id, post_id, meta_value AS old_slug FROM wp_postmeta WHERE meta_key = '_wp_old_slug' ORDER BY post_id ASC;А вот запрос на удаление:
DELETE FROM wp_postmeta WHERE meta_key = '_wp_old_slug';Снова обмолвлюсь, что префикс у вас может быть другой.
Если вам интересно, как еще можно повлиять на производительность и ускорить загрузку страниц, загляните в мой обзор настроек плагина Clearfy >>
