Перейти к содержимому 
Я покажу вам, как именно вы можете Уменьшить размер базы данных, без потери содержания: от быстрых решений с плагинами до контролируемых шагов MySQL. Это позволит вам сократить Время загрузки, Сервер освобожден от нагрузки, и вы сохраняете полный контроль над всеми изменениями.
Центральные пункты
Прежде чем работать с таблицами, я уточняю цели, защищаю базу данных и решаю, какие шаги по очистке действительно необходимы. Таким образом, я избегаю рисков, сохраняю минимальный объем обслуживания и достигаю измеримого эффекта. Следующие пункты целенаправленно проведут вас через весь процесс. Вы получите четкую последовательность действий, практические советы и рекомендации по типичным "подводным камням". После этого вы будете проводить оптимизацию безопасно и повторяемо.
- Резервное копирование Первый: Полное резервное копирование и тест воспроизведения
- Плагины использовать: WP-Optimise, WP-Sweep, Advanced Database Cleaner
- phpMyAdminОптимизация таблиц, очистка переходных процессов
- wp_options с первого взгляда: Проверка автозагрузки и устаревших загрузок
- Автоматизируйте: Регулярные работы по очистке и мониторингу
Я расставляю приоритеты в зависимости от воздействия и риска, начинаю с кандидатов на безопасное удаление и перехожу к более глубоким вмешательствам. Это позволяет сохранить веб-сайт данные остаются нетронутыми, а база данных становится предсказуемо более компактной.
Почему базы данных WordPress растут - и что действительно важно
В повседневной работе вы быстро накапливаете Пересмотр, спам-комментарии, удаленное содержимое в корзине и истекшие переходные периоды. Такие записи увеличивают время выполнения запросов, раздувают таблицы и увеличивают CPU-потребление. Особенно страдают wp_posts (ревизии), wp_postmeta (мета-балласт), wp_options (переходные процессы, автозагрузка) и wp_comments (спам, мусор). Кроме того, после многочисленных удалений в таблицах MySQL образуется навес, который замедляет выполнение запросов. Решение проблемы роста на ранней стадии экономит ресурсы, сокращает время до первого байта и обеспечивает чистоту данных.
Точный диагноз: что на самом деле растет?
Прежде чем удалить, я измеряю. В phpMyAdmin я отображаю данные и размер индекса для каждой таблицы и определяю главных потребителей. Если вы хотите быть более точным, используйте обзор через INFORMATION_SCHEMA и сортируйте по общему количеству данных:
SELECT
имя_таблицы,
ROUND((data_length + index_length)/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;
Вот как я узнаю, например, можно ли. wp_postmeta преобладает из-за большого количества метаданных о продукте или SEO. Важно: физический размер файла не всегда сразу уменьшается при использовании InnoDB; ОПТИМИЗИРОВАТЬ СТОЛ освобождает память внутри таблицы и - с помощью file_per_table - также на уровне файловой системы. Я документирую начальные и целевые значения, чтобы сделать выгоду от каждой меры видимой.
Резервное копирование: как создать резервную копию данных
Прежде чем удалить что-то, я экспортирую База данных полностью и протестировать восстановление. В phpMyAdmin я выбираю БД, нажимаю "Экспорт" и сохраняю SQL-файл локально. Проверенный плагин для резервного копирования также может создать вторую резервную копию. Я всегда проверяю, включает ли резервная копия все таблицы и префиксы, особенно если речь идет о многосайтовости или изменении Префиксы таблиц. Только когда резервное копирование и восстановление работают, я начинаю очистку.
Постановка, откат и минимизация времени простоя
Я планирую вмешательства таким образом, чтобы сайт оставался доступным. Для этого я сначала работаю - если это возможно - в Этапный экземпляр, Я тестирую самые важные потоки (вход, оформление заказа, поиск) и только потом переношу шаги в живую систему. Я планирую большие запуски удаления вне времени основных посещений, отключаю кэширование незадолго до запуска, очищаю его после запуска и проверяю журнал ошибок. Для отката я держу наготове проверенную резервную копию БД и записываю каждый запрос в журнал изменений, чтобы можно было отменить изменения.
Плагины для очистки базы данных wordpress в повседневной жизни
Для выполнения рутинных задач я в первую очередь полагаюсь на WP-Optimise, потому что он обрабатывает ревизии, спам, корзину, переходные процессы и таблицы в один прием. После установки я активирую автоматическую очистку и планирую еженедельные запуски. При необходимости я использую WP-Sweep для пингбэков/трекбэков и Advanced Database Cleaner для очистки осиротевших записей. Записи для выявления конкретных кандидатов. Перед удалением я проверяю предварительный просмотр, отключаю рискованные опции и подтверждаю только четкие кандидатуры. Таким образом, я добиваюсь заметного эффекта с минимальными усилиями и могу автоматизировать процедуру „wp optimise database“.
Ручная оптимизация в phpMyAdmin: сохраняйте контроль
Если мне нужно больше контроля, я переключаюсь на phpMyAdmin и отсортируйте таблицы по размеру. Я оптимизирую больших кандидатов с помощью выпадающего списка, который внутренне использует команду ОПТИМИЗИРОВАТЬ СТОЛ и уменьшает нависание. Я удаляю просроченные переходные процессы с помощью DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';. Я удаляю неиспользуемые теги с помощью DELETE FROM wp_terms WHERE term_id NOT IN (SELECT term_id FROM wp_term_taxonomy);. После каждого шага я проверяю сайт и журнал ошибок, прежде чем приступить к дальнейшей очистке, чтобы Риски остаются небольшими.
Безопасная очистка ревизий, спама и корзины.
Пересмотр может быть полезен, но он раздувает рынок до бесконечности. wp_posts на. Я ограничиваю их с помощью define('WP_POST_REVISIONS', 3); в wp-config.php и удалите старые ревизии с помощью плагина. Я регулярно очищаю спам и мусор; это уменьшает размер wp_comments заметно. Я также просматриваю автоматические черновики и удаляю дубликаты. После каждого удаления я снова запускаю оптимизацию таблицы, чтобы действительно освободить память.
Держите wp_options в чистоте: Автозагрузка и переходные процессы
Стол wp_options часто вызывает скрытые задержки, особенно при больших значениях автозагрузки. Я измеряю общий объем автозагружаемых опций и останавливаю чрезмерно большие записи, которые загружаются при каждом вызове. Я регулярно удаляю просроченные переходные процессы, потому что в противном случае они занимают место и увеличивают время запуска. Если вы хотите ознакомиться с предысторией и типичными источниками нагрузки, вы можете найти подробную информацию на сайте Понимание переходных процессов. После очистки я проверяю фронтэнд и бэкэнд, чтобы обнаружить влияние на Время загрузки проверить.
Простой запрос помогает мне быстро оценить нагрузку автозагрузки: SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';. Я нахожу отдельные выбросы с помощью SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 20;. Я установил для больших, редко используемых значений автозагрузку = ’нет‘ и обеспечил, чтобы плагин загружал их специально, когда это необходимо.
Целенаправленная оптимизация таблиц: Что приносит наибольшую пользу?
Вместо того чтобы бессистемно удалять все подряд, я сосредоточился на таблицах с наибольшими Эффект. wp_posts и wp_postmeta часто оказывают самое сильное влияние, за ними следуют wp_options и wp_comments. Затем я провожу сравнение до и после в phpMyAdmin, чтобы оценить прогресс. Такая прозрачность минимизирует риск и показывает, где стоит провести следующий раунд. Следующий обзор классифицирует типичные результаты и подходящие действия, чтобы вы могли действовать структурированно.
| Таблица | Причина | Типичный балласт | Рекомендуемая мера | Риск |
|---|---|---|---|---|
| wp_posts | Изменения, дизайн автомобилей | Десятки пересмотров каждого вклада | Ограничение/удаление ревизий, оптимизация | Низкий уровень для резервного копирования |
| wp_postmeta | Старые метазаписи | Осиротевшие мета-ключи | Удаление осиротевших метаданных, проверка индексов | Средства, проверьте заранее |
| wp_options | Переходные процессы, автозагрузка | Данные кэша с истекшим сроком хранения | Удаление переходных процессов, уменьшение автозагрузки | От низкого до среднего |
| wp_comments | Спам, корзина для мусора | Проблемы наследия и волны спама | Массовое удаление, установка автоматики | Низкий |
Особый случай WooCommerce и магазинов с высокой посещаемостью
Магазины генерируют больше среднего количества записей данных в wp_postmeta (вариации, атрибуты, метаданные заказа) и заполните wp_options с сессиями и переходными периодами. Я регулярно удаляю истекшие сессии/переходные периоды, сокращаю время хранения неисправных корзин и проверяю, не хранятся ли в теме или плагинах ненужные метаданные о товаре. Я поддерживаю таблицы планировщика действий (например, as_actions) в небольшом объеме, очищая завершенные задания раньше и не перепланируя бесконечно неудачные задания. Я планирую дополнительный раунд после больших продаж или импорта. ОПТИМИЗИРОВАТЬ СТОЛ, для быстрого уменьшения свеса.
Возможности многосайтовости
В сетях балласт умножается на все блоги. Я перехожу от сайта к сайту, обращая внимание на префиксы независимых таблиц (например. wp_2_) и дополнительно очистить Переходные процессы в сети на сайте _сайт_переходный_*. Для глобальных таблиц (например, wp_users, wp_usermeta) я ничего не удаляю, но проверяю зависимости между сайтами. Я планирую задания по очистке вне окон синхронизации или миграции, чтобы сохранить согласованность сети.
Продвинутые шаги по настройке MySQL WordPress
При интенсивном движении я обращаю внимание на InnoDB-настройки и индексы. Правильно рассчитанный буферный пул и значимые индексы на часто фильтруемых столбцах (например, meta_key в wp_postmeta) значительно ускоряют запросы. Кэширование запросов существует и в старых версиях MySQL, но современные системы больше выигрывают от хорошего кэширования на уровне приложений или объектов. Кроме того, я избегаю больших записей в автозагрузке, которые замедляют раннюю загрузку страницы; подробности можно найти на сайте Параметры автозагрузки. После каждого тюнинга я снова провожу измерения, чтобы определить влияние на Время реагирования чтобы проверить.
Индексы под контролем: проверенные и испытанные схемы
Я специально проверяю, насколько разумно поддерживаются типичные фильтры. Для wp_postmeta индексы были основаны на (post_id) и - в зависимости от запросов - в (meta_key, post_id) доказано. На сайте wp_options по умолчанию есть индекс на имя_опции; для запросов после автозагрузки я использую существующий (автозагрузка)-индекс или комбинируйте фильтры с LIMIT. Прежде чем добавлять индексы, я моделирую наиболее частые запросы, измеряю время их выполнения и учитываю, что индексы занимают много памяти и могут удлинить процесс записи. Я удаляю лишние или избыточные индексы, если они не приносят ощутимой пользы.
WP-CLI на практике: быстрая очистка с помощью скриптов
Если есть доступ к оболочке, я ускоряю работу с помощью WP-CLI. Примеры, которые я использую в окнах обслуживания:
- Очистите переходные процессы:
wp transient delete --expiredи если потребуетсяwp transient delete --all - Опустошите корзину для спама/бумаги:
wp comment delete --status=spam --force,wp comment delete --status=trash --force - Сократите количество пересмотров:
wp post list --post_type='post,page' --field=ID --post_status=publish | xargs -n100 wp post delete-revision - Оптимизируйте базу данных:
оптимизация базы данных wpи проверьте размеры с помощьюwp db size --tables
Эти команды можно интегрировать в задания cron или сценарии развертывания. Я начинаю с команд чтения (списки, подсчеты), подтверждаю выбор и только потом выполняю команды удаления.
Набор символов, разрядность и формат строк
Несогласованные наборы символов увеличивают риски при миграции и могут ограничивать индексы к текстовым столбцам. Если возможно, я переключаюсь на utf8mb4 с последовательной сверткой (например. utf8mb4_unicode_ci). Перед переключением я делаю резервную копию БД, проверяю этапное обновление и конвертирую таблицы в контролируемые шаги. Для таблиц InnoDB я использую текущий формат строк (например. ДИНАМИКА), так что длинные TEXT/VARCHAR могут быть эффективно заменены. В сочетании с innodb_file_per_table=ON предоставляет ОПТИМИЗИРОВАТЬ СТОЛ обеспечивает возврат свободного пространства в файловую систему.
Автоматизация: планировать чистоту, а не надеяться
Я экономлю время, выполняя повторяющиеся задания прекратить. В WP-Optimize я настраиваю еженедельную очистку и ежемесячную оптимизацию таблиц. Кроме того, системный cron может надежно запускать собственный cron WordPress, чтобы запланированные задачи не отменялись. Для повторяющихся действий, таких как „wp optimise database“, я устанавливаю фиксированные временные окна вне основного времени посещения. Это позволяет постоянно поддерживать базу данных в тонусе без необходимости запускать каждый шаг вручную.
Мониторинг и тестирование: сделать успех заметным
После каждого раунда я проверяю Размер БД в phpMyAdmin и документирую развитие. Я проверяю, как изменяется Time-to-First-Byte и Largest Contentful Paint. Я обращаю внимание на заметное увеличение wp_options или wp_postmeta на ранних стадиях, пока они не повлияли на производительность. Эта статья дает полезную пищу для размышлений о постоянно чистых опциях: Сохраните wp_options. В то же время я веду журнал изменений с указанием даты, мер и результата, чтобы впоследствии иметь возможность отслеживать решения.
Ключевые цифры и пороговые значения для практического использования
Я определяю четкие границы, чтобы оптимизация не зашла в тупик. Примеры: Не допускать, чтобы общий объем автозагрузки не превышал 1-2 МБ; wp_postmeta в связи с wp_posts правдоподобно (без веских оснований никаких коэффициентов, превышающих 20-50x); доля переходных процессов в wp_options не растут. Что касается производительности, я регулярно измеряю TTFB, поисковые запросы в бекенде (например, список товаров) и время загрузки админки. Если основные показатели увеличиваются или таблицы внезапно сдвигаются, я начинаю целенаправленный анализ, а не просто удаляю все подряд.
Систематическое удаление "бесхозных" таблиц и остатков деинсталляции
Многие плагины оставляют после себя таблицы и опции. Я перечисляю неосновные таблицы по префиксам, собираю кандидатов и действую в два этапа: Сначала я переименовываю таблицу в тестовую (например. Переименуйте таблицу wp_altplugin_data в wp_altplugin_data_backup;) и слежу за состоянием страницы. Если все остается стабильным, я удаляю таблицу навсегда. В wp_options Я ищу типичные пространства имен плагинов (имя_опции LIKE '%pluginname%') и удалять только те записи, функции которых я понял. Для wp_usermeta и wp_postmeta Я определяю осиротевшие ключи, проверяя, существуют ли еще идентификаторы, на которые они ссылаются.
Избегайте распространенных ошибок
Я никогда не удаляю без Резервное копирование и проверьте воспроизведение. Я выполняю рискованное массовое удаление в wp_postmeta только после анализа осиротевших мета-ключей. Я использую очистку плагинов выборочно, а не активирую все опции. После удаления я очищаю кэш и тестирую функции, чтобы ни одна из секций страницы не завершилась неожиданно. Если что-то остается неясным, я сначала работаю на промежуточном экземпляре и переношу очистку на живую систему только после успешного тестирования.
Краткое резюме
С четкой последовательностью, чистой Резервное копирование с помощью нескольких инструментов можно оптимизировать любую базу данных WordPress без потери данных. Я начинаю с безопасных кандидатов, таких как переходные периоды, спам и ревизии, оптимизирую таблицы и ограничиваю будущий рост с помощью правил. Для больших установок я использую ручные шаги в phpMyAdmin и разумные пункты настройки MySQL. Автоматизированные процедуры позволяют поддерживать базу данных стабильно маленькой и ощутимо быстрой. Если вы будете следовать этим рекомендациям, вы уменьшите размер, снизите нагрузку на сервер и заметно ускорите страницы - предсказуемо, безопасно и понятно.
