База данных WordPress: wp_posts, postmeta, options и почему сайт начинает тормозить

Autoload, postmeta, индексы и тяжёлые запросы.

Хорошая архитектура означает, что контент можно менять без программиста, повторяемые сущности не копируются вручную, интеграции журналируют ошибки, а новая функция не требует переписывать половину темы.

Симптом и причина — не одно и то же

Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.

Что проверить в первую очередь

• Проверить тему, child theme и точки кастомизации до обновления.
• Измерить SQL, autoload и cron.
• Измерить autoload options и найти аномально большие записи.
• Проверить версии PHP, WordPress и критических плагинов на совместимость.
• Для больших однотипных наборов оценить отдельную таблицу и индексы.

Как сузить круг причин

В WordPress важно отделить симптом от источника: тема, плагин, запрос к БД, cron, интеграция или сервер могут выглядеть одинаково — «сайт глючит».

WordPress сам по себе не делает сайт быстрым или медленным. Результат определяют тема, плагины, модель данных, запросы к БД, сервер и процесс обновлений. Большой проект лучше воспринимать не как набор страниц, а как приложение с сущностями и связями.

Чего я бы не делал на старте

• править ядро или файлы плагинов напрямую
• ставить несколько плагинов с одной функцией
• делать тяжёлые WP_Query внутри циклов
• отправлять данные в CRM без логов

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

Что сравнить после исправления

• autoload size
• время PHP-ответа
• ошибки интеграций
• число SQL-запросов

Я бы фиксировал изменения через staging, логи и измерения до/после. Иначе легко удалить полезную функцию и оставить настоящую причину.