Оптимизация MySQL для WooCommerce: Когда база перестаёт успевать

Знаете это ощущение? Вроде бы всё сделал правильно: HPOS включил, Redis подключил, OPcache настроил. А магазин всё равно думает. Открываешь список товаров — пауза. Фильтруешь по категории — пауза. Сохраняешь заказ — и тут база берёт передышку на три секунды.

Знакомо? Тогда у меня для вас новость. Проблема не в PHP. Не в Nginx. Не в медленном хостинге. Проблема — в MySQL.

База данных WooCommerce — это как склад, на котором свалено всё подряд. Товары, заказы, мета-данные, сессии, логи. И когда вам нужно найти конкретную коробку, кладовщик бегает по всему складу, потому что нормального каталога нет. Только список «всего, что когда-либо сюда привозили».

Сегодня разберёмся, как навести порядок на этом складе. Добавим индексы, почистим мусор, настроим MySQL под нагрузку WooCommerce. Без магии. Только конкретные команды и реальные цифры.

Шаг 1. Диагностика: где именно тормозит?

Прежде чем что-то оптимизировать, нужно понять, что именно тормозит. Иначе можно потратить день на настройку my.cnf, а проблема окажется в отсутствующем индексе.

Через Query Monitor

Устанавливаем Query Monitor, открываем страницу магазина и смотрим вкладку «Запросы к БД». Сортируем по времени выполнения.

Что должно насторожить:

• Запросы дольше 50 мс — уже проблема
• Запросы дольше 200 мс — серьёзная проблема
• Запросы с Using filesort или Using temporary — MySQL не может использовать индексы
• Десятки одинаковых запросов — нет кэширования

Через slow query log

Если у вас VPS, включите лог медленных запросов. В /etc/mysql/my.cnf добавьте:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Перезапустите MySQL:

sudo systemctl restart mysql

Через сутки посмотрите лог:

sudo mysqldumpslow -s t -t 20 /var/log/mysql/slow.log

Эта команда покажет 20 самых медленных запросов. Обычно в топе — запросы к wp_postmeta и wp_wc_orders_meta.

Шаг 2. Индексы для wp_postmeta (главная боль WooCommerce)

Таблица wp_postmeta — это самое узкое место WooCommerce. Здесь хранятся цены, остатки, атрибуты товаров, настройки плагинов. И по умолчанию в ней только один индекс — по post_id.

Когда WooCommerce ищет товары по цене, он сканирует миллионы строк. Представьте, что вы ищете книгу в библиотеке, где каталог есть только по автору, а вы помните только год издания.

Добавляем составные индексы

-- Индекс для поиска по ключу и значению (фильтры товаров)
ALTER TABLE wp_postmeta 
ADD INDEX idx_meta_key_value (meta_key, meta_value(191));

-- Индекс для поиска товаров по цене
ALTER TABLE wp_postmeta 
ADD INDEX idx_price (meta_key, meta_value(10));

-- Индекс для поиска по наличию на складе
ALTER TABLE wp_postmeta 
ADD INDEX idx_stock (meta_key, meta_value(3));

Зачем указывать длину meta_value(191)? Потому что meta_value — это LONGTEXT, а MySQL не может индексировать такие поля целиком. Ограничиваем длину индекса 191 символом — этого хватает для большинства значений (цены, SKU, статусы).

Проверяем результат

После добавления индексов выполним тот же запрос, что тормозил раньше:

EXPLAIN SELECT post_id, meta_value 
FROM wp_postmeta 
WHERE meta_key = '_price' 
AND meta_value BETWEEN '100' AND '500';

Смотрим колонку type. Если было ALL (полный скан таблицы), а стало range — поздравляю, индекс работает. Время запроса упадёт с 800 мс до 5-10 мс.

Шаг 3. Индексы для таблиц WooCommerce (HPOS)

Если вы включили HPOS, заказы хранятся в отдельных таблицах. Но и там нужны индексы для быстрой фильтрации.

-- Индекс для поиска заказов по статусу и дате
ALTER TABLE wp_wc_orders 
ADD INDEX idx_status_date (status, date_created_gmt);

-- Индекс для поиска заказов по email клиента
ALTER TABLE wp_wc_order_addresses 
ADD INDEX idx_email (email(191));

-- Индекс для поиска заказов по телефону
ALTER TABLE wp_wc_order_addresses 
ADD INDEX idx_phone (phone(20));

-- Индекс для мета-данных заказов
ALTER TABLE wp_wc_orders_meta 
ADD INDEX idx_meta_key (meta_key);

Эти индексы ускоряют фильтрацию заказов в админке. Если раньше список заказов открывался 5 секунд, теперь будет 0.5 секунды.

Шаг 4. Очистка мусора (то, что копится годами)

WordPress и WooCommerce создают много временных данных. Ревизии постов, спам-комментарии, просроченные транзенты, сессии. Всё это лежит в базе и замедляет запросы.

Удаляем ревизии постов

Ревизии — это история изменений записей. Полезно, когда вы пишете статью. Бесполезно, когда у вас 50 000 ревизий для 500 товаров.

# Через WP-CLI (безопасно)
wp post delete $(wp post list --post_type=revision --format=ids) --force

# Или оставляем только последние 5 ревизий для каждого поста
wp post delete $(wp post list --post_type=revision --format=ids | awk '{for(i=6;i<=NF;i++) print $i}') --force

Через phpMyAdmin (быстрее, но осторожно):

-- Удаляем все ревизии
DELETE FROM wp_posts WHERE post_type = 'revision';

-- Удаляем мета-данные ревизий
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.post_type = 'revision';

Чистим транзенты

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

# Удаляем просроченные транзенты
wp transient delete --expired

# Удаляем все транзенты (осторожно, кэш сбросится)
wp transient delete --all

Удаляем спам-комментарии

# Через WP-CLI
wp comment delete $(wp comment list --status=spam --format=ids) --force

Чистим сессии WooCommerce

WooCommerce хранит сессии покупателей в опциях. Если у вас много посетителей, опций может стать десятки тысяч.

-- Удаляем старые сессии (старше 48 часов)
DELETE FROM wp_options 
WHERE option_name LIKE '_wc_session_%' 
AND option_value < UNIX_TIMESTAMP(NOW() - INTERVAL 48 HOUR);

Оптимизируем таблицы после очистки

После удаления данных таблицы не уменьшаются в размере автоматически. Нужно выполнить OPTIMIZE TABLE:

# Через WP-CLI
wp db optimize

Или через phpMyAdmin — выберите все таблицы и в выпадающем меню выберите «Оптимизировать таблицу».

Шаг 5. Настройка my.cnf под WooCommerce

Стандартная конфигурация MySQL рассчитана на маленькие сайты. Для WooCommerce нужно увеличить буферы и кэши.

Открываем /etc/mysql/my.cnf (или /etc/my.cnf) и добавляем в секцию [mysqld]:

[mysqld]
# Буфер InnoDB (главный параметр!)
# Должен быть 70-80% от свободной RAM
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2

# Лог транзакций (безопасность vs скорость)
# 1 = максимальная безопасность, медленнее
# 2 = баланс безопасности и скорости (рекомендуется)
# 0 = максимально быстро, но риск потери данных при сбое
innodb_flush_log_at_trx_commit = 2

# Размер лога InnoDB (больше = быстрее запись)
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M

# Кэш запросов (для повторяющихся SELECT)
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 2M

# Максимум подключений (для высокой нагрузки)
max_connections = 200
max_user_connections = 100

# Таймауты (чтобы медленные запросы не вешали базу)
wait_timeout = 60
interactive_timeout = 60

# Буферы для сортировки и JOIN
sort_buffer_size = 2M
join_buffer_size = 2M
read_buffer_size = 1M
read_rnd_buffer_size = 1M

# tmpdir в RAM (если есть свободная память)
tmp_table_size = 64M
max_heap_table_size = 64M

Перезапускаем MySQL:

sudo systemctl restart mysql

Как рассчитать innodb_buffer_pool_size?

Это самый важный параметр. Он определяет, сколько данных MySQL держит в оперативной памяти.

Формула простая:

# Узнаём размер всех InnoDB-таблиц
mysql -e "SELECT SUM(data_length + index_length) / 1024 / 1024 / 1024 AS 'Size (GB)' FROM information_schema.tables WHERE engine = 'InnoDB';"

# Результат умножаем на 1.5 — это и есть нужный buffer_pool_size

Если базы 2 ГБ, ставим innodb_buffer_pool_size = 3G. Если у вас сервер с 8 ГБ RAM — это нормально. Если сервер с 4 ГБ RAM — ставьте 2G, иначе не хватит памяти для PHP и Nginx.

Шаг 6. Мониторинг производительности MySQL

Настроили базу, добавили индексы, почистили мусор. Теперь нужно следить, чтобы всё оставалось быстрым.

Проверяем hit rate InnoDB

Hit rate показывает, какой процент запросов обслуживается из памяти, а не с диска. Должен быть выше 99%.

mysql -e "SHOW ENGINE INNODB STATUS\G" | grep "Buffer pool hit rate"

Если hit rate ниже 95% — увеличьте innodb_buffer_pool_size.

Смотрим количество медленных запросов

# Считаем медленные запросы за последний час
grep -c "Query_time:" /var/log/mysql/slow.log

# Или через mysqladmin
mysqladmin -i 60 -c 10 extended-status | grep -i "slow_queries"

Если количество медленно растёт — значит, появляется новый тяжёлый запрос. Пора разбираться.

Автоматический мониторинг через скрипт

Создаём /usr/local/bin/mysql-monitor.sh:

#!/bin/bash

# Проверяем hit rate
HIT_RATE=$(mysql -e "SHOW ENGINE INNODB STATUS\G" | grep "Buffer pool hit rate" | awk '{print $4}')

# Проверяем количество подключений
CONNECTIONS=$(mysql -e "SHOW STATUS LIKE 'Threads_connected';" | grep Threads_connected | awk '{print $2}')

# Проверяем медленные запросы за последний час
SLOW_QUERIES=$(grep -c "Query_time:" /var/log/mysql/slow.log 2>/dev/null || echo 0)

# Алерт в Telegram, если что-то не так
if [ "$HIT_RATE" -lt 95 ] || [ "$CONNECTIONS" -gt 150 ] || [ "$SLOW_QUERIES" -gt 100 ]; then
    curl -s -X POST "https://api.telegram.org/bot$BOT_TOKEN/sendMessage" \
        -d chat_id="$CHAT_ID" \
        -d text="⚠️ MySQL Alert:
Hit Rate: ${HIT_RATE}%
Connections: $CONNECTIONS
Slow Queries (last hour): $SLOW_QUERIES"
fi

Добавляем в cron:

# Каждые 15 минут
*/15 * * * * /usr/local/bin/mysql-monitor.sh

Шаг 7. Оптимизация запросов WooCommerce (для разработчиков)

Если вы пишете кастомный код для WooCommerce, важно правильно строить запросы. Несколько правил:

Используйте WC_Product_Query вместо WP_Query

Плохо:

// Тяжёлый запрос с мета-полями
$products = new WP_Query( array(
    'post_type'  => 'product',
    'meta_query' => array(
        array(
            'key'     => '_price',
            'value'   => array( 100, 500 ),
            'compare' => 'BETWEEN',
            'type'    => 'NUMERIC',
        ),
    ),
) );

Хорошо:

// Использует внутренние таблицы WooCommerce
$products = wc_get_products( array(
    'status'   => 'publish',
    'limit'    => 20,
    'orderby'  => 'price',
    'order'    => 'ASC',
    'min_price' => 100,
    'max_price' => 500,
) );

Избегайте N+1 запросов

Плохо:

// Делает отдельный запрос для каждого товара
foreach ( $product_ids as $id ) {
    $product = wc_get_product( $id );
    $price = $product->get_price();
    // ...
}

Хорошо:

// Один запрос с кэшированием
$products = wc_get_products( array(
    'include' => $product_ids,
    'return'  => 'objects',
) );

foreach ( $products as $product ) {
    $price = $product->get_price();
    // ...
}

Используйте транзенты для тяжёлых запросов

function get_top_selling_products() {
    $cache_key = 'top_selling_products';
    $products = get_transient( $cache_key );
    
    if ( false === $products ) {
        // Тяжёлый запрос
        $products = wc_get_products( array(
            'limit'    => 10,
            'orderby'  => 'popularity',
            'return'   => 'objects',
        ) );
        
        // Кэшируем на час
        set_transient( $cache_key, $products, HOUR_IN_SECONDS );
    }
    
    return $products;
}

Чек-лист оптимизации MySQL

• ✅ Включён slow query log, проанализированы самые медленные запросы
• ✅ Добавлены индексы для wp_postmeta (meta_key + meta_value)
• ✅ Добавлены индексы для таблиц HPOS (статусы, email, телефон)
• ✅ Удалены ревизии постов (оставлены только последние 5 для каждой записи)
• ✅ Удалены просроченные транзенты
• ✅ Удалены спам-комментарии
• ✅ Очищены старые сессии WooCommerce
• ✅ Выполнена оптимизация таблиц (OPTIMIZE TABLE)
• ✅ Настроен innodb_buffer_pool_size (70-80% от свободной RAM)
• ✅ Настроен innodb_flush_log_at_trx_commit = 2 (баланс скорости и безопасности)
• ✅ Настроен мониторинг hit rate и медленных запросов
• ✅ Кастомные запросы используют wc_get_products() вместо WP_Query
• ✅ Тяжёлые запросы кэшируются через транзенты

Результаты оптимизации (реальные цифры)

Вот что получилось на магазине с 15 000 товаров и 45 000 заказов после всех шагов:

Разница колоссальная. Особенно заметно на операциях с фильтрацией товаров и поиском заказов.

Решение частых проблем

После добавления индексов база стала тормозить ещё сильнее

Это нормально при первом добавлении индексов — MySQL перестраивает таблицы. Подождите 10-30 минут, пока процесс завершится. Проверить можно так:

mysql -e "SHOW PROCESSLIST;" | grep -i "alter table"

InnoDB hit rate низкий, хотя buffer_pool_size большой

Возможно, у вас слишком много таблиц, и они не помещаются в память. Проверьте размер базы:

mysql -e "SELECT SUM(data_length + index_length) / 1024 / 1024 / 1024 AS 'Size (GB)' FROM information_schema.tables WHERE engine = 'InnoDB';"

Если размер базы больше, чем innodb_buffer_pool_size — увеличьте буфер или почистите мусор.

Медленные запросы появляются снова после очистки

Значит, WooCommerce или плагин генерирует новые временные данные. Настройте автоматическую очистку через cron:

# Каждый день в 3 часа ночи
0 3 * * * wp transient delete --expired --path=/var/www/wordpress
0 3 * * * wp comment delete $(wp comment list --status=spam --format=ids --path=/var/www/wordpress) --force --path=/var/www/wordpress

MySQL падает с ошибкой "Out of memory"

Слишком большой innodb_buffer_pool_size. Уменьшите его до 60% от RAM. Также проверьте max_connections — если слишком много одновременных подключений, каждое съедает память.

Итог

Оптимизация MySQL для WooCommerce — это не разовая акция, а постоянный процесс. Добавили индексы — база ускорилась в 20-70 раз. Почистили мусор — освободили место и ускорили запросы. Настроили my.cnf — увеличили hit rate до 99%.

Но самое главное — это мониторинг. База данных — живой организм. Она растёт, меняется, иногда болеет. Нужно следить за ней, как за садом: поливать (добавлять индексы), пропалывать (чистить мусор), удобрять (настраивать конфигурацию).

Начните с простого: включите slow query log, посмотрите, какие запросы тормозят, добавьте индексы. Этого хватит, чтобы ускорить базу в 10-20 раз. Потом переходите к настройке my.cnf и автоматической очистке.

И помните: быстрая база — это не роскошь. Это необходимость. Когда клиент ждёт загрузки страницы 3 секунды, он уходит к конкуренту. Когда админка тормозит на 10 секунд при сохранении заказа — вы теряете время и нервы. Оптимизация MySQL решает обе проблемы.