profitrushПривет всем, помогите с SQL запросом.

Есть таблица с несколькими сотнями тысяч записей

id | rate

1 | 15
2 | 15
3 | 10
4 | 20
5 | 25
6 | 20
7 | 15

Мне надо сделать выборку под критерий - сумма рейтинга 32

Мне нужен вывод:

id | rate

1 | 15
2 | 15
3 | 10

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

Таблица InnoDB, эта операций выполняется как часть транзакции, в таблице тысячи записей поэтому необходимо чистая и быстрая реализация :)

Это типа роллап задача, решается на переменных. Посмотрите топик
выборка ТОП-Н записей в FAQ. Там идет последовательная нумерация
для каждой категории (допустим для каждого язера в вашем случае).
Вместо нумерации можно сделать роллап сумму .
(надо посмотреть внимательно. Наверно надо сумму НЕ включая текушаю запись)
Это на первом прогоне. затем просто выбрать записис где роллап_сумма < 32.

Два прогона на 200К записей займет 100-300 мс на среднем железе
с правильными индексами и правильным кодом.

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

profitrushВ буржунете подсказали вариант, отлично подошел)
единственное мне не нравиться LIMIT 0 , 999999

хотелось бы без него реализацию(






ну, если скорость устроит, то ОК.
Лимит 0,30 это, наверно у вас в ПХП,
в МуСКЛ-е такого дефолта нет.

profitrush,

код , похоже, правильный.
Это у вас что-то с типом данных, может ИНТ вместо ДЕЦИМАЛ(10,2)

miksoftjavajdbcкод , похоже, правильный.не похоже.
1) сортировка по price, а JOIN по id
2) сортировка по полю, которого нет в группировке.

А уж быстродействием тут и не пахнет.


Сортировка идет (как я понимаю) после отсечки по HAVING,
поэтому 1) неважно.
Про 2) --- это случай когда PRICE аттрибуте однозначно зависит от
GROUP BY ИД аттрибута, поэтому его не обязательно окружать
груповой функцией.

Быстродействие тут стандартное для полного перемножения в группе.
Если скорость устроит, то и ладно.
Ускорение, может быть (а может и нет, зависит от данных):
1) перебором первых значений с быстрой остановкой на лимите (ваш первый вариант)
2) ролап на переменных (мой вариант, оставленый без внимания, наверно сложнее других)
3) расчет каждого значения на тригере при вставке.
4) может еше что-то ?

miksoftjavajdbc,

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

нет , я никогда не кодировал процедуры на МуСКЛ.
Мне хватило нескольких лет тежелого кодирования на PL/SQL :-)
Обычно очисткой курсора должен заниматся код фреймворка.
Выход из цикла кусора есть в любом языве высокго уровня,
так что это не должно быть проблемой.

miksoftjavajdbcОбычно очисткой курсора должен заниматся код фреймворка.
Выход из цикла кусора есть в любом языве высокго уровня,
так что это не должно быть проблемой.Так вот с точки зрения MySQL тут что происходит?

Не в курсе. Давным давно драйверы тупо выбирали все записи и
грузили в память. Потом появились бач-подгрузки по , например 100 записей.
в любой момент позле подгрузки следуюшуй партии драйвер
может закрыть курсор. Так что ускорение точно будет
на (умном) клиенте, если
он загрузит первые 100 записей и остановить цикл через 15 записей...
и остальные 100К не будут грузится вообше.

Более детально что происходит внутри я не знаю.