Работа с БД WordPress
2.65K subscribers
Оптимизация и прямая работа с таблицами базы данных WordPress.
Download Telegram
Резервная копия базы WordPress, которая реально спасает, а не просто лежит на сервере

Если бэкап нельзя восстановить за 10 минут — это не страховка, а архив. Для WordPress критично проверять не только наличие файлов, но и целостность: дамп базы должен открываться, а таблицы — совпадать по структуре и кодировке.

Что должно быть в нормальном бэкапе:
• база данных целиком, без выборочных таблиц;
• файлы wp-content: темы, плагины, uploads;
• понятное имя архива и дата создания;
• отдельное хранение вне основного хостинга.

Частая ошибка — хранить только .sql и забывать про медиа. После восстановления сайт поднимается, но картинки, кастомная тема или кэш-папки пропадают. Ещё хуже — делать копию поверх живой базы без проверки: один битый экспорт, и восстановление уже не из чего.

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

Хороший бэкап — это тот, который уже однажды восстановили без сюрпризов.
5 ошибок в SQL-запросах, из-за которых WordPress тормозит и ломает БД

Чаще всего проблема не в самой базе, а в запросе, который к ней обращается. В WordPress это особенно заметно на больших таблицах: один лишний JOIN, полный перебор строк или сортировка без индекса — и страница уже грузится дольше.

• Не используйте SELECT * без нужды: тянете лишние поля и увеличиваете нагрузку.
• Не фильтруйте по функциям от поля: так индекс часто не работает.
• Избегайте ORDER BY RAND() на больших выборках — это дорогая операция.
• Не делайте запросы внутри цикла, если можно собрать данные одним SQL.
• Проверяйте, есть ли индекс под WHERE и JOIN: без него MySQL ищет вслепую.

Для WordPress отдельно важны WP_Query и прямые запросы через $wpdb. Если нужен сложный фильтр — сначала посмотрите, можно ли решить задачу стандартным запросом, а не собирать кастомную логику. И всегда смотрите EXPLAIN: он быстро показывает, где запрос уходит в полный скан.

Если запрос медленный, начните не с оптимизации сервера, а с разбора текста SQL: в нём обычно уже спрятана причина.