Оптимизация базы данных WordPress’а и перенос
24 марта 2009 / Кухня сайтов
Закончился перенос баз данных «Российского музыканта» и fragilité на новый сервер. Теперь переезд осуществлен полностью.
В процессе переноса базы пришлось оптимизировать, ибо WordPress их раздувает до немыслимых размеров. Например, база «Российского музыканта» занимала 60 мегабайт, что неимоверно много и серьезно усложняет переезд. За счет чего нарастают такие объемы? (для сравнения — «Война и мир» занимает немногим больше трех мегабайт, а объем «Российского музыканта» пока и близко не подошел к этому роману)
Оптимизация базы данных WordPress
Во-первых, WordPress по умолчанию множит ревизии записи (можно вручную отключить либо ограничить их число), сохраняя каждый вариант отдельным постом. С одной стороны, это удобно, позволяет в случае необходимости вернуться к старому варианту (такая необходимость иногда возникает). С другой — если хотя бы сократить число этих ревизий, а у старых записей (где они уже совсем не нужны) вообще их стереть, то можно в разы уменьшить объем базы данных.
Как это сделать? Все ревизии хранятся в общей таблице wp_posts с указанным типом (post_type) revision. Но ни в коем случае нельзя просто удалить все подобные посты: информация о них хранится еще и в других таблицах. Это:
- wp_postmeta — здесь прописывается все метаинформация для каждого поста. В том числе, например, все дополнительные поля (Custom Fields, туда прописывают информацию многие плагины) и множество полей вида _edit_last и _edit_lock. Они относятся к функции совместного редактирования (кто последний раз редактировал запись — это указывается в поле meta_value цифрой, соответствующей ID пользователя, и кто ее сейчас редактирует).
- wp_term_relationships — в ней фиксируются связи постов с рубриками и тэгами (ну и связи ссылок, но они просто не используются ни на РМ, ни на fragilité) из таблицы wp_terms. И эти связи записываются для каждой ревизии.
Реально каждый пост еще связан с таблицей wp_comments, в которой здесь указывается, к какому посту принадлежит комментарий (поле comments_post_ID). Но там не упоминаются ревизии, насколько я понимаю (хотя указаний в Кодексе на их наличие или отсутствие тоже не вижу). Хотя, честно, и странно было б, если бы они там упоминались 
Итого, нужно удалить все эти ревизии, одновременно подчистив все их связи в других таблицах. Есть уже готовые варианты решения в виде запросов для MySQL: первый, прочищающий таблицы wp_posts, wp_postmeta и wp_term_relationships; второй, трогающий еще и таблицу wp_comments. Запросы просто удаляют все записи, соответствующие постам таблицы wp_posts типа revision.
Во-вторых, сильно (хоть и не настолько безумно, как от ревизий) разрастаются таблицы с комментариями (в том числе спамовыми, число которых более чем в 10 раз превышает число полезных) и таблицы, где хранятся запросы WordPress’овской доски объявлений. Что с ними делать? Да удалять, если занимают слишком много места. Вполне достаточно будет запроса вида:
DELETE FROM wp_comments WHERE comment_approved = ’spam’;
Но это сильно зависит от того, что используется в качестве антиспама.
Схема взаимосвязей таблиц WordPress 2.7
После этого
Быстрый и спокойный перенос, переключение — и вуаля, теперь сайты зависят только от своего сервера (иными словами — чужие падения их не касаются
