Как отличить объём базы от дорогих запросов и autoload, составить безопасный отчёт, найти владельца данных и проверить точечное исправление без массовой очистки.
Сначала подтвердите, что задержка относится к базе
Медленная страница не означает автоматически медленную базу. Запрос может ждать внешний API, выполнять обработку изображения, запускать PHP-код или стоять в очереди обработчика. Начните с конкретной операции: открытие каталога, поиск, сохранение товара, импорт или кабинет. Запишите адрес, состояние входа, время и последовательность. Без воспроизводимого сценария любое уменьшение базы будет случайным действием.
У базы есть разные характеристики: занятый объём, число строк, объём данных, загружаемых при старте приложения, количество запросов и длительность каждого. Маленькая таблица с неудачным запросом может мешать сильнее большой таблицы архива. Нельзя оценить состояние по одному числу мегабайт в панели и обещать ускорение после удаления всех «лишних» записей.
Разделите три направления диагностики
| Наблюдение | Что оно показывает | Чего не доказывает |
|---|---|---|
| Объём таблицы | Занятое хранение и рост | Что именно она тормозит текущую страницу |
| Autoload | Данные, загружаемые как общий набор опций | Что все эти настройки ненужны |
| Профиль запросов | Время и повторения для операции | Что результат переносится на весь сайт |
| Длительность страницы | Суммарное ожидание и выполнение | Что причина обязательно в SQL |
Для каждой гипотезы нужен свой факт. Если импорт постоянно создаёт журнал, контролируйте рост и правила хранения. Если дорого собирается каталог, анализируйте конкретный запрос. Если при каждом запуске загружается большой набор опций, выясняйте владельцев и частоту использования. Эти задачи связаны, но не заменяют друг друга.
Пример правильной постановки
Вместо «база весит много» запишите: «поиск в каталоге в одинаковой тестовой сессии медленнее обычного просмотра; в профиле виден повторяющийся запрос определённого компонента». Это ещё не вывод о виновнике, но уже проверяемая гипотеза, по которой разработчик может собрать план выполнения и исключить другие слои.
Подготовьте копию и среду для анализа
Перед изменением базы сохраните согласованную копию и проверьте восстановление в отдельное окружение. Для активного магазина учтите новые заказы: возврат всей базы после эксперимента может удалить рабочие изменения. Поэтому точечные испытания сначала выполняют на изолированном стенде с нужной структурой и обезличенными данными, а рабочее исправление оформляют отдельным шагом.
Снимите версии WordPress, плагинов, СУБД и префикс таблиц. Не предполагайте, что у проекта префикс wp_. Если доступны CLI-команды, проверьте каталог установки и пользователя выполнения. Даже команда чтения в контексте WordPress запускает приложение и его плагины, поэтому выполняйте её с согласованными правами и пониманием фоновых эффектов проекта.
- Закройте копию от внешних интеграций и реальной оплаты.
- Назначьте окно наблюдения и один исследуемый сценарий.
- Храните дампы и отчёты вне публичных каталогов.
- Не пересылайте option_value: там могут быть ключи и персональные данные.
Соберите отчёт по autoload без вывода значений
Autoload — механизм загрузки опций, а не отметка «мусор». Состав загружаемого набора зависит от версии WordPress; в современных ветках встречается несколько значений признака. Используйте поддерживаемый интерфейс своей версии вместо старого SQL, который считает только autoload=yes и затем объявляет результат полным. Для первого отчёта достаточно имён и размеров, без содержимого настроек.
wp option list --autoload=on --fields=option_name,size_bytes --format=csv
wp option list --autoload=on --format=total_bytesСохраните дату, версию инструмента и область выборки. Итоговый размер не является универсальным порогом аварии. Важно, какие данные попадают в общий набор, как часто нужны и создаёт ли это подтверждённую проблему. Не публикуйте имена опций, раскрывающие внутренние интеграции, если отчёт предназначен для открытого доступа.
Найдите владельца крупной опции
Начните с документации и кода компонента, который создаёт настройку. Префикс имени — подсказка, а не достаточное доказательство владельца. Один плагин может хранить лицензию, карту маршрутов, параметры доставки или результаты временной операции. Удаление строки без понимания назначения способно сбросить рабочую настройку, а не только освободить память.
Для каждого кандидата ответьте: активен ли владелец, нужны ли данные на обычных запросах, как они обновляются, есть ли штатное изменение режима загрузки и предусмотрена ли очистка при удалении компонента. Если плагин выключен, его настройки могут понадобиться при возвращении. Отдельно согласуйте срок хранения и возможность восстановления. Отсутствие активного плагина не даёт права уничтожить неизвестные данные.
| Поле реестра | Пример записи без секретов |
|---|---|
| Имя и размер | Идентификатор настройки и размер из отчёта |
| Владелец | Подтверждённый компонент и его версия |
| Назначение | Что перестанет работать при отсутствии данных |
| Частота | Каждый запрос или редкая административная операция |
| Действие | Оставить / изменить загрузку / штатно удалить после согласования |
| Возврат | Сохранённое значение и исходный режим |
Изменение autoload не равно удалению настройки
Если разработчик подтвердил, что опция редко нужна, возможна смена режима автозагрузки при сохранении значения. Современный WordPress предоставляет для этого штатный API, но наличие функции зависит от установленной версии. Применение должно быть точечным, с известными именами и восстановлением исходного признака. Не превращайте пример API в команду для всех крупных строк.
После изменения проверьте не только главную, но и редкую операцию, которая использует настройку: вход в сервис, обновление лицензии, расчёт доставки или генерацию карты. Уменьшение общего набора может добавить отдельный запрос при обращении к опции; это допустимо только при корректной работе и обоснованном результате. Внешний объектный кэш тоже учитывается в процедуре инвалидации.
Как исследовать медленные запросы
Попросите разработчика или администратора собрать профиль именно проблемного действия. Нужны текст запроса без секретов, длительность, число повторений, вызывающий компонент и условия воспроизведения. Средство наблюдения выбирают под окружение; не устанавливайте случайный плагин на рабочий магазин только ради одной цифры. Подробный сбор сам может добавлять нагрузку и раскрывать содержимое запросов.
EXPLAIN помогает изучить план выполнения, но его вывод требует понимания версии СУБД, индексов, условий и объёма данных. EXPLAIN ANALYZE может выполнять исследуемый запрос, поэтому не следует считать любой вариант безопасным описанием без исполнения. На рабочей базе метод и область выбирает специалист. Добавление индекса меняет запись и хранение данных и тоже требует испытания.
- Воспроизведите одно действие в одинаковом контексте.
- Отделите SQL от ожидания внешней сети и PHP.
- Найдите повторяемый дорогой запрос и компонент.
- Проверьте план и гипотезу на стенде.
- Внесите одно исправление и повторите тот же сценарий.
- Проверьте операции записи и соседние функции.
Не удаляйте transient, сессии и журналы одной командой
Срок жизни и назначение временных данных отличаются. Действующая сессия корзины не является безусловным мусором, а журнал может быть нужен для разбирательства заказа. Массовая очистка во время работы магазина способна изменить поведение посетителей и создать дополнительную нагрузку на пересоздание кэша. Используйте штатные средства компонента и документированные сроки хранения.
Если таблица быстро растёт, сначала устраните причину: повторяемый сбой, бесконечную постановку задач, избыточное журналирование или отсутствие регламента очистки. Разовое уменьшение размера без изменения причины только отложит повторение. Сохраните необходимое доказательство инцидента до очистки. Не включайте клиентские данные в публичный отчёт об оптимизации.
Проверьте исправление и подготовьте возврат
Повторите исходную операцию в сопоставимых условиях, разделив холодный и прогретый кэш. Сохраните профиль до и после, изменение конфигурации и результаты функций. Не обещайте конкретный процент ускорения по одному запросу: задержка зависит от данных, конкуренции и других слоёв. Если результата нет, это повод пересмотреть гипотезу, а не расширять удаление.
Для точечного изменения autoload сохраняйте исходное значение признака; для кода — предыдущую версию; для схемы базы — отдельный план миграции и возврата. Не восстанавливайте полную старую базу поверх новых заказов ради отмены одной настройки. После возврата подтвердите работоспособность и сохранность текущих данных. Результат должен быть воспроизводим другим специалистом по вашему протоколу.
FAQ и итоговый реестр
Большая база всегда означает медленный сайт?
Нет. Нужен профиль конкретной операции. Объём хранения, выбранный план запроса и загрузка опций — разные характеристики.
Можно ли удалить все настройки неактивных плагинов?
Сначала подтвердите владельца, назначение и возможность восстановления. В них могут храниться параметры, необходимые для возвращения компонента.
Достаточно ли SQL с autoload=yes?
Для полного актуального набора это может быть неверно: представление признака менялось. Используйте поддерживаемые средства своей версии WordPress и WP-CLI.
Redis устраняет необходимость анализа запросов?
Нет. Он может изменить стоимость повторных обращений, но не исправляет плохой запрос, неверную инвалидацию или ненужную запись данных.
Передайте владельцу реестр исследованных данных, подтверждённое исправление, функциональные результаты и порядок возврата. Если задержка не связана с базой, зафиксируйте это и продолжайте диагностику другого слоя. Покупка более дорогого VPS не заменяет установление причины.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
