Форум пользователей MySQL

Покажите структуру таблиц, т.е. результат
show table cms3_object_types;
и так для всех 5ти таблиц из запроса


И ещё SHOW VARIABLES;

Не менять запрос - серьезное ограничение, но чтобы понять причину попробуйте сделать так:
1) убрать DISTINCT
2) поочередно выкидывайте JOIN внешних таблиц (кроме o) и смотрите после какого выбрасывания запрос ускорится.
3) сделайте профайлинг запроса

По конфигу:
innodb_buffer_pool_size должен быть меньше объема памяти. Сделайте, например, 6Гигов

Нет, в этом случае уменьшать не надо. Просто от первого поста было впечатление, что её всего 12.

Очень хорошо. Не до конца понятно почему copying to tmp table занимает основное время, но понятна связь с o_asteriks. Скорее всего из-за условия o_asteriks.text_val LIKE '...', полный текст попадает в таблицу, которая потом сортируется. Может быть, возможно избавиться от условия на полный текст в рамках текущей CMS?

rgbeast написал:

Очень хорошо. Не до конца понятно почему copying to tmp table занимает основное время, но понятна связь с o_asteriks. Скорее всего из-за условия o_asteriks.text_val LIKE '...', полный текст попадает в таблицу, которая потом сортируется. Может быть, возможно избавиться от условия на полный текст в рамках текущей CMS?

К сожалению нет. Запросы конструируются специальным php классом. Его изменение во первых может непонятно как отразиться на построении других запросов, а во вторых лишает меня поддержки и гарантии на систему, так как это внесение изменений в исходный код приложения (cms коммерческая).

vasya написал:

Имхо, "copying to tmp table" включает в себя и группировку. Теоретически может помочь переход на более поздние версии, где временные таблицы создаются с hash индексом.

o_asteriks вообще в запросе не нужна. Перенеся условие на oc_230_lj за счет oc_230_lj.field_id =  '230' мы получим всего 1 строку, т.е. временная таблица будет меньше почти в 10 раз. Отсюда и ускорение.

Вот и я примерно так понял, когда анализировал запрос. Есть мысль: раз нельзя исправить запрос, то может попробовать увеличить скорость copying to tmp table путем переноса на tmpfs (начитался тут пытаясь разобраться)? Временные таблицы ведь создаются на физическом диске, правильно я понимаю?

vasya написал:

Нет в оперативной, если не превышают max_heap_table_size и tmp_table_size и хватает памяти.
Можно проверить через show status

Каким это проверить? Что именно надо смотреть?

Насколько я знаю, UmiCMS достаточно гибкая система. 6 секунд на запрос - это разве не гарантийный случай? Думаю, что техподдержка должна сделать для вас необходимые модификации (тем более вы знаете в чем дело - нужно исключить поиск по полному тексту). Сам на практике с Umi не сталкивался, но это как раз характеризует систему положительно - значит ваш случай скорее исключение.

По конфигурации - мало шансов на успех, но попробовать стоит. Приведите:

@rБУzzz написал:

В том то и дело, что техподдержка ответила, что помочь не могут, т.к. это уже проблема разработчиков, а они вносить такого рода изменения во второй ветке системы уже не будут, т.к. заняты допиливанием третьей ветки.

Наши люди везде найдут выход
Можно сделать заплатку после того как запрос сконструирован, но перед отправкой в базу. И регулярным выражением его: если вид такой, то меняем на другой. Это не изменит остальные запросы и не сильно помешает вам обновлять систему.
Перед обращением за гарантией, уберете заплатку
Жесть конечно, но может и помочь.


Со стороны MySQL можно лишь расчитывать на некоторое ускорение в версиях где временная таблица создается с hash индексом.

MySQL 5.6 / MariaDB 5.5
Но в доке сказано про временную таблицу из from-подзапроса. По идее эта оптимизация должна быть доступна и в остальных случаях, но нужно проверять.

vasya написал:

MySQL 5.6 / MariaDB 5.5
Но в доке сказано про временную таблицу из from-подзапроса. По идее эта оптимизация должна быть доступна и в остальных случаях, но нужно проверять.

В общем ясно, что без изменения формируемого запроса обойтись не получится. Посмотрю можно ли обновить СУБД до более свежей версии. Спасибо Вам большое за помощь и участие.

rgbeast написал:

Задал вопрос в Facebook UMI.CMS: https://www.facebook.com/UMI.CMS/posts/ … ream_ref=5

Ответили, что решение вас устроило

Да, пока я тут пытался решить проблему по сложному, они мне объяснили, что просто я не в том поле ищу по номеру заказа.
Мне мои менеджеры настолько вынесли мозг, что я не разобравшись, что именно и куда они вбивают, полез сразу в недра системы. По факту есть отдельное поле для номера заказа, поле куда они вбивали номер - предназначено для общего поиска по содержимому всех полей всех заказов. Именно поэтому там такой большой запрос и такой медленный.
Ту инфу, что удалось накопать в процессе поиска, я им продублировал, возможно это поможет как откорректировать логику конструктора запросов.

Очень удивился, что в они так оперативно реагируют в Facebook. Может лучше писать туда, а не в техподдержку

rgbeast написал:

Задал вопрос в Facebook UMI.CMS: https://www.facebook.com/UMI.CMS/posts/ … ream_ref=5

Ответили, что предложенное решение вас устроило

Да и Вы в Facebook написали Пользователи не смогли получить помощь от техподдержки UmiCMS. Это не совсем верно. Ребята из СЗ пытались мне помочь. Копию мой БД даже развернули у себя на сервере, что протестировать, что именно может работать не так. Поиск через поле "Поиск" действительно работает медленно и тут они ничего сделать не могут, но они объяснили, что я просто не там ищу.
Вообще упрекнуть их в нежелании помогать нельзя, тут они молодцы.