MasterZivHettНу вот конкретно с

пропущено...


проблема, прям вот конкретно с ним.

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Вы мне третий раз уже этот вопрос задаете. Я 2 раза уже ответил. Думаю третий раз уже не стоит.

MasterZivHettЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу.

чего делали ?

https://www.google.ru/search?q=mysql fragmented tables&oq=mysql fragmented tables&aqs=chrome..69i57j0l5.233j0j7&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8

netwindMasterZivпропущено...


Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ.
Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию.

Откуда вы взяли эту информацию? Из другой темы? Там был совсем другой запрос и таблица.

Я первом же посте написал ддл таблицы, на секции бьются по HASH(id) :)

netwindHett, так это означает что партиции вообще никак ничего не ускоряют в первом приближении. Приходится согласиться со всем о чем MasterZiv написал .
Какие-то другие эффекты и настройки могли что-то изменить, но с позиции оптимизатора SQL работы меньше не стало.

Да я понимаю, как уже и говорил, ускорения и не ждал. но 10 кратное замедление (не зависящее от количества партиций) насторожило просто, подумалось может какого буфера не хватает, поэтому на форуме тему и создал. Как показали "опыты", в 5.6 такой проблемы нет, мы решили перейти на продакшене на версию 5.6, и проблема в общем-то отпала. Возможно просто в 5.5 этот момент хуже реализован и пересмотрен в 5.6.