Внимание! Портал Московской консерватории «Российский музыкант 2.0» закрыт 31 августа 2009 года в связи с расформированием Научного отдела по работе с интернет-сайтом. Это архивная копия (15 сентября 2008 года — 31 августа 2009 года).

Оптимизация базы данных 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

После этого

Быстрый и спокойный перенос, переключение — и вуаля, теперь сайты зависят только от своего сервера (иными словами — чужие падения их не касаются :)

Откликнуться