Збільшення бази даних WordPress не завжди означає проблему. Інтернет-магазин, сайт із великою кількістю замовлень, коментарів або користувачів закономірно зберігає більше інформації. Однак надмірний обсяг бази може уповільнювати адміністративну панель, створювати помилки під час резервного копіювання та збільшувати навантаження на сервер.
Очищення потрібно виконувати обережно. Видалення таблиць, записів або службових даних без перевірки може призвести до втрати налаштувань, замовлень, контенту чи працездатності окремих функцій. Перед будь-якими змінами варто створити резервну копію і переконатися, що її можна відновити.
Що займає місце в базі WordPress
Стандартна база WordPress складається з таблиць, у яких зберігаються записи, сторінки, коментарі, облікові записи, налаштування та метадані. Додаткові плагіни часто створюють власні таблиці або записують інформацію у загальні таблиці WordPress.
Найчастіше обсяг збільшують:
- ревізії записів і сторінок, які створюються під час редагування;
- автозбереження та записи в кошику;
- спам-коментарі й невидалені коментарі;
- тимчасові дані — transients і кеш окремих плагінів;
- записи в таблиці
wp_options, зокрема великі або завантажувані автоматично параметри; - метадані записів, користувачів і замовлень;
- журнали помилок, дій користувачів, імпорту, платежів або синхронізації;
- залишки деактивованих плагінів і тем;
- таблиці плагінів, які накопичують статистику, логи чи історію змін.
Назва префікса таблиць не обов’язково є стандартною wp_, тому перед роботою потрібно перевірити фактичну структуру бази. Збільшення розміру також може бути наслідком не сміття, а великої кількості важливих даних. Наприклад, видалення записів із таблиць замовлень без розуміння зв’язків може порушити роботу магазину.
Як створити контрольну копію перед очищенням
Резервну копію слід створити до очищення, оптимізації або видалення плагінів. Бажано зберегти не лише файли сайту, а й окремий дамп бази даних. Файлова копія без бази не містить записів, налаштувань, користувачів і замовлень, а дамп бази без файлів не відновить код теми чи плагінів.
- Перевірте, де саме зберігаються поточні резервні копії та чи не розміщені вони на тому самому сервері.
- Створіть нову повну копію файлів і бази даних перед внесенням змін.
- Завантажте копію в окреме безпечне місце, недоступне з публічної частини сайту.
- Переконайтеся, що архів відкривається, а файл бази не пошкоджений і має очікуваний розмір.
- За можливості перевірте відновлення на тестовому домені або локальному стенді.
Якщо сайт приймає замовлення, заявки чи платежі, не варто виконувати масштабне очищення без узгодження періоду робіт. Навіть невелика помилка під час експорту або імпорту може призвести до неповної копії. Не видаляйте резервну копію одразу після очищення: збережіть її доти, доки не перевірите роботу сайту та коректність даних.
Ревізії transient-сміття і журнали плагінів
Ревізії допомагають повернути попередню версію запису або сторінки, але на сайтах із тривалим активним редагуванням їх може накопичитися дуже багато. Видаляти всі ревізії без розбору не обов’язково: частина з них може бути потрібна редакторам. Безпечніше визначити політику зберігання, наприклад обмежити кількість ревізій для нових записів і поступово прибрати надлишкові старі версії.
Transients — це тимчасові значення, які WordPress і плагіни використовують для кешування результатів запитів, API-відповідей та інших даних. Прострочені transients зазвичай можна очищати, але активні тимчасові записи не слід видаляти під час критичних операцій магазину або синхронізації. Після очищення плагіни можуть тимчасово виконувати більше запитів і навантажувати сервер.
Особливої уваги потребує таблиця wp_options. Великі записи з параметром автозавантаження можуть завантажуватися під час кожного запиту до сайту. Проте видалення невідомого параметра небезпечне: ним може користуватися активна тема або плагін. Спочатку потрібно визначити джерело запису, перевірити його призначення та лише потім вирішувати, чи можна його видалити.
Журнали плагінів також не завжди є сміттям. У них можуть зберігатися дані про помилки платежів, імпорт товарів, спроби входу або синхронізацію. Перед очищенням потрібно:
- визначити, який плагін створює таблицю або записи;
- з’ясувати, чи потрібні журнали для аудиту та пошуку помилок;
- зберегти журнал окремо, якщо він може знадобитися;
- використовувати штатну функцію очищення плагіна, якщо вона передбачена;
- не видаляти таблиці активних плагінів вручну без документації та резервної копії.
Якщо після деактивації плагіна залишилися великі таблиці, це ще не означає, що їх можна одразу видалити. Спочатку потрібно переконатися, що інший компонент сайту не використовує ці дані.
Як оптимізувати таблиці без простою
Оптимізація таблиць може звільнити невикористаний простір і покращити внутрішню структуру бази після великої кількості змін. Водночас ця операція не замінює очищення: якщо таблиця містить мільйони непотрібних записів, оптимізація лише впорядкує вже наявний обсяг.
Перед оптимізацією потрібно перевірити:
- яку систему керування базою даних використовує сервер;
- чи достатньо вільного дискового простору для тимчасових операцій;
- чи не виконується резервне копіювання, імпорт або обробка замовлень;
- чи має користувач бази необхідні права;
- чи не перевищує операція допустиме навантаження на сервер.
На невеликому сайті оптимізацію можна виконувати через перевірений інструмент керування базою або надійний плагін, але спершу потрібно ознайомитися з його режимом роботи. На великих базах краще виконувати операції поетапно та контролювати час блокування таблиць. Деякі дії можуть тимчасово обмежити запис даних, тому під час пікового навантаження вони здатні спричинити помилки або втрату нових заявок.
Після оптимізації перевірте головну сторінку, авторизацію, форму контакту, пошук, кошик, оформлення замовлення та адміністративну панель. Для магазину додатково потрібно перевірити статуси замовлень і підключення платіжних та облікових сервісів. Якщо база пошкоджена, з’явилися помилки з’єднання або сайт перестав зберігати дані, не повторюйте операцію — відновіть копію або зверніться до спеціаліста.
Як контролювати подальше зростання бази
Разове очищення не усуне причину, через яку база постійно збільшується. Після діагностики варто визначити, який компонент створює найбільше записів, і налаштувати контроль.
- Встановіть обмеження на кількість ревізій і період зберігання тимчасових даних.
- Налаштуйте автоматичне видалення старих журналів, якщо вони не потрібні для довготривалого аудиту.
- Перевіряйте, чи не записує плагін помилки в базу на кожному запиті.
- Контролюйте розмір таблиці
wp_optionsі параметрів, що автоматично завантажуються. - Не встановлюйте кілька плагінів із функціями кешування, статистики або резервного копіювання без потреби.
- Плануйте регулярні резервні копії та періодично перевіряйте можливість їх відновлення.
- Оновлюйте WordPress, тему та плагіни після перевірки сумісності, оскільки помилки старих версій можуть спричиняти неконтрольоване накопичення даних.
Звернення до спеціаліста потрібне, якщо база швидко зростає без очевидної причини, сайт працює нестабільно, з’являються помилки MySQL, пошкоджені таблиці, дублікати записів або невідомі користувачі. Також не варто самостійно видаляти дані, якщо сайт пов’язаний із замовленнями, оплатами, CRM чи обліком клієнтів.
Безпечна робота з базою WordPress починається не з кнопки «очистити», а з діагностики: визначення найбільших таблиць, джерела записів, залежностей між даними та наявності перевіреної резервної копії. Такий підхід допомагає зменшити зайве навантаження, не ризикуючи працездатністю сайту та важливою інформацією.