Skip to content
 

Оптимизация индексов UMI CMS

Эта ЦМС всем хороша - удобная, красивая, быстрая... пока количество страниц сайта исчисляется десятками. Но если попытаться поднять на ней например городской новостной портал, то неожиданно обнаружится, что вся красивость далась дорогой ценой, а идея реализовать объектный движок исключительно через метаданные, эмулируемые "игрушечной" реляционной БД, оказывается принципиально негодной. Ибо все, ВСЕ объекты хранятся в единой таблице (пухнущей как на дрожжах), которая многократно JOIN-ится сама с собой по разным условиям. В результате время выполнения одного запроса с легкостью превышает 10 секунд, а время генерации одной страницы уходит в бесконечность.

Пришлось заниматься :) Как оказалось, авторы этой ЦМС совершенно не знают, как работает MySql - в результате почти все сложные запросы выполняются прямым перебором, без использования индексов. Нет, индексы таблицах конечно есть - проиндексировано каждое поле... вот только MySql умеет использовать при обращении к таблице только ОДИН индекс!
(И даже в версии 5.1, где вроде бы имеется Index Merge Optimization, реальный план запроса показывает использование только одного индекса...)

Разобравшись с причиной, устранение - дело техники. Даем sql-серверу указание сохранять медленные запросы, смотрим лог, и добавляем недостающие индексы по всем используемым в условии полям.

В моем случае получилось так:
alter table `cms3_hierarchy` ADD INDEX `idx_complex` (`is_active`,`is_deleted`,`lang_id`,`domain_id`),
ADD INDEX `idx_active` (`is_active`,`is_deleted`), ADD INDEX `rel_lype_lang` (`rel`,`is_active`,`type_id`,`lang_id`,`is_deleted`),
ADD INDEX `rel_act` (`rel`,`is_deleted`,`is_active`,`lang_id`), ADD INDEX `icomplex_5` (`is_active`,`is_deleted`,`lang_id`,`type_id`,`rel`), ADD INDEX`type_lang_dom` (`type_id`,`lang_id`,`domain_id`,`is_deleted`,`obj_id`);

alter table `cms3_object_content` ADD INDEX `idx_complex` (`obj_id`,`field_id`), ADD INDEX `idx_complex2` (`obj_id`,`field_id`,`int_val`),
ADD INDEX `idx_complex3` (`obj_id`,`field_id`,`rel_val`), ADD INDEX `idx_complex4` (`obj_id`,`field_id`,`tree_val`);

alter table cms3_objects ADD INDEX `type_name` (`type_id`,`name`);

alter table cms3_permissions ADD INDEX `idx_complex` (`level`,`owner_id`),
ADD INDEX `id_full` (`owner_id`,`rel_id`,`level`), ADD INDEX `rel_owner` (`rel_id`,`owner_id`),
ADD INDEX `rel_level` (`rel_id`,`level`);

alter table cms3_search ADD INDEX `domain_lang` (`domain_id`,`lang_id`), ADD INDEX domain_lang_rel (`domain_id`,`lang_id`,`rel_id`);

alter table cms3_search_index ADD INDEX `rel_word` (`rel_id`,`word_id`);

alter table cms3_search_index_words ADD UNIQUE `id_word` (`id`,`word`(32));

После этого не то чтобы летает, но 600 запросов в секунду выдерживает.

Также можно почитать:

  1. Два видео по теме
  2. Новый сайт

5 комментариев

  1. Вася (Нижний Новгород) пишет:

    Нравится или нет: Thumb up Thumb down 0

    не сталкивался случайно с тем, что при переносе (при мультисайтовости) из одного сайта через модуль структуру в другой, каталоги, то они пропадают из индекса поиска. то есть метод search_do их не видит. При импорте из csv для этого нужно в config.ini  указывать import-auto-index = "1", а вот что указывать что бы они попали опять в индекс поиска при их переносе с сайта на сайт...?

    Ответить на комментарий
    • admin admin пишет:

      Нравится или нет: Thumb up Thumb down 0

      Уважаемый, вы меня с техподдержкой этого глюкала (юми) не спутали? Я ее тогда увидел первый раз в жизни, и надеюсь что в последний.

      Ответить на комментарий
  2. Вася (Нижний Новгород) пишет:

    Нравится или нет: Thumb up Thumb down 0

    А вот теперь:
    такую штуку кстати выдал при проверки таблиц (CHECK TABLE `city_list`, `cms3_c)

    Проблемы с индексами таблицы `cms3_cluster_nodes`
    Индексы PRIMARY и node_id равнозначны и один из них может быть удалён.
    Проблемы с индексами таблицы `cms3_messages_inbox`
    Индексы recipient_id и FK_MessagesInbox to User равнозначны и один из них может быть удалён.
    Индексы message_id и FK_MessagesInbox to Messages равнозначны и один из них может быть удалён.
    Проблемы с индексами таблицы `cms3_objects_expiration`
    Индексы PRIMARY и FK_ObjectsExpire to objects равнозначны и один из них может быть удалён.  

    Ответить на комментарий
  3. Вася (Нижний Новгород) пишет:

    Нравится или нет: Thumb up Thumb down 0

    Кстати у меня эти индексы уже стаяли, когда устанавливал.
    сначала через phpmyadmin показалось, что их нет... а потом открыл ссылку +Индексы и там все увидел.. 

    Ответить на комментарий
    • admin admin пишет:

      Нравится или нет: Thumb up Thumb down +1

      Дык сколько времени с тех пор прошло! Юми таки ж мониторят интернет в поиске инфы про свое глюкало, не случайно ИМЕНА индексов остались практически без изменения!

      Ответить на комментарий

Написать отзыв