[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mysql select: сочетание order by по составному индексу и limit



 r> Надеюсь у разработчиков MySQL были весомые причины по разному
 r> использовать индекс в двух запросах:

 r> 1) select ... order by F1 limit N
 r> 2) delete ... order by F1 limit N

 r> прим: F1 - первое поле составного индекса

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

возможно это и так, к тому же ситуация полностью укладывается в стандарт SQL, то есть нельзя сказать что select вернул не тот набор данных,
которые задали "order by F1"

кстати
1) select ... order by F1 limit N
2) select ... order by F1
тоже различаются возвращаемому набору, в части пересечения естественно

И все-таки, по моему мнению, это как если бы sprintf и fprintf по разному отрабатывали форматную строку.

Ставлю точку и сдаюсь :) , свою задачу я решил.


А вообще использовать order by ... limit в delete - решение
категорически непереносимое, и рекомендуется им не пользоваться без
крайней необходимости.

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


Стандартный (в смысле SQL-92) delete умеет
только where.


P.S. если что, простите за дубли, пора с яндекса бежать



Reply to: