Як оптимізувати 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 →