Как оптимизировать MariaDB для WordPress

Краткий ответ: Задайте innodb_buffer_pool_size так, чтобы рабочий набор умещался в RAM (25–50% RAM сервера на совмещённой web+DB машине), включите slow-query log и уберите мусор на стороне WordPress: раздутый autoload в wp_options, ревизии постов и транзиенты. За большинством жалоб на «медленную админку» стоит именно задержка базы.

Обзор

WordPress на InnoDB живёт или умирает от buffer pool: когда горячие данные в нём умещаются, запросы отвечают из RAM. Второй рычаг — найти несколько плохих запросов (обычно плагин) через slow log. Третий — гигиена WordPress: строки с autoload в wp_options грузятся на каждом запросе, и плагины обожают их туда пихать.

Что нужно иметь

• Картину RAM из free -h, размер базы из:

  sudo mariadb -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables GROUP BY table_schema;"

• Свежий бэкап перед изменениями конфигурации.

Пошаговая инструкция

1. Создайте /etc/mysql/mariadb.conf.d/60-wordpress.cnf (пример для VPS на 4 GB с полным стеком):

   [mysqld]
   innodb_buffer_pool_size = 1G
   innodb_log_file_size    = 256M
   max_connections         = 100
   slow_query_log          = 1
   slow_query_log_file     = /var/log/mysql/slow.log
   long_query_time         = 1

   затем sudo systemctl restart mariadb.
2. Через день прочитайте slow log и исправьте или замените проблемный плагин/запрос (индекс добавляйте только когда понимаете запрос).
3. Уменьшите autoload-раздутие:

   sudo -u www-data wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb FROM wp_options WHERE autoload IN ('yes','on');"
   sudo -u www-data wp db query "SELECT option_name, LENGTH(option_value) len FROM wp_options WHERE autoload IN ('yes','on') ORDER BY len DESC LIMIT 15;"

   Всему от давно удалённых плагинов можно выключить autoload или удалить. Здоровый суммарный объём: до ~800 KB.
4. Ограничьте ревизии и чистите протухшие транзиенты в wp-config.php / cron:

   define('WP_POST_REVISIONS', 10);

   sudo -u www-data wp transient delete --expired
5. Проверьте эффективность buffer pool после прогретого дня: SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; — чтений с диска должна быть мизерная доля от запросов на чтение.

Типичные проблемы

• Buffer pool слишком большой: MariaDB убивает OOM под PHP-нагрузкой — на совмещённой машине оставляйте большую часть RAM для PHP + кеша ОС.
• Slow log забивает диск: держите long_query_time от 1 с и ротируйте лог.
• Миллионы строк транзиентов: плохо ведущий себя плагин — удалите протухшие и найдите автора записей, пока не наросло снова.

Когда обращаться в поддержку

Тюнинг базы на неуправляемом VPS — ваша зона, но когда узким местом становится именно IO (высокий disk wait при правильном buffer pool), спросите о NVMe-планах — базам данных NVMe помогает больше всего.

Частые вопросы

Какая настройка MariaDB важнее всего для WordPress?

innodb_buffer_pool_size — она решает, сколько базы живёт в RAM. Когда рабочий набор умещается, большинство запросов вообще не трогают диск, и весь сайт ощущается быстрее.

Что такое autoload-опции и почему они важны?

Строки wp_options с флагом autoload грузятся на каждом запросе. Плагины копят их годами; суммарный объём свыше ~1 MB ощутимо замедляет все страницы, поэтому проводите аудит и чистку.

Как найти плагин, замедляющий базу данных?

Включите slow-query log MariaDB с long_query_time=1 и дайте сайту поработать день — лог назовёт конкретные запросы, а Query Monitor в wp-admin припишет их определённому плагину.

Похожие статьи

• Как починить медленную админку WordPress
• Как ускорить WordPress на VPS
• Как оптимизировать PHP для WordPress
• Как установить MariaDB или MySQL

Готовы начать? Заказать WordPress VPS в Cloud2Y →