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

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

Вах маладец! Спасибо, да, дарагой, приходи чаще,
рады будем, приходи и сразу говори как надо.
Реально поможеш -- братаны не будут головы ломать.
Пиво будем кушать, кальмаров кушать,
красивых девочек танцеват.

всегда пожалуста...могу больше сказать.

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

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

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

пример(первый)



первый запрос выдаст результат на подобе этого
1 10 1
1 20 11
1 123 21
1 4 124
1 0 5
тоесть вычисление третьего значения, проиходит использую сумму предыдущей группы

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

ЗЫ
Если рассуждать более строго (мускл и насколько я понимаю отсальные субд тоже)
то запись
select id,@t:=id+1,@tt:=@t+1

не следует ожидать что для айди = 1 мы получим 1 2 3

это как со значением переменой цикла фор после самого цикла, она всегда равна макс значение щётчика плюс один, но везде говорят, что не надо на это ращитывать, ибо хз как завтра может измениться компилятор/интерпритатор... данный момент не стандартизирован - пока что так.

так вот порядок обработки столбцов тоже не специфицирован, более того - реляционная модель как раз таки подразумевает, что от порядка столбцов ничего не зависит.

ращитывать что пулучим 1 2 3 , тоже что ращитывать при
select * from table получим записи отсортированые по примари кею автоинкрементному.

таки да, получим - в большинстве случаев, но в меньшинстве изза работы оптимизатора это
не так.

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