Пересортировка результата запроса к БД (resource of type (mysql result))

[Сергей Тарасов]

Автор оригинала: baev
Лично мне — как пользователю — было бы интересно упорядочить по другому полю все записи. А кому и зачем может понадобиться то сакральное действо, которое Вы описали, я себе представить не могу...

Ну, в некоторых ситуациях это может сильно сэкономить время на многочисленных сортировках по разным полям нечасто меняющегося массива данных.
Кстати, классический похожий пример - нужно сделать выборку, например топ 100 по одному критерию, а потом отсортировать по другому, например по названию... самое простое - вложенный запрос SELECT * FROM (SELECT ... ORDER BY ... LIMIT 0, 100) AS tbl ORDER BY tbl. работает очень медленно, т.к. вторая сортировка выполняется без индексов...


Прекрасно понимаю, что автору и большинству это совершенно не нужно, но мне было бы интересно, если бы кто-то предложил или рассказал про то, о чем говорил автор... Сорри за ОФФТОП.

 

[baev]

Кстати, классический похожий пример - нужно сделать выборку, например топ 100 по одному критерию, а потом отсортировать по другому, например по названию... самое простое - вложенный запрос SELECT * FROM (SELECT ... ORDER BY ... LIMIT 0, 100) AS tbl ORDER BY tbl.

Не понял: отсортировать уже выбранные 100 записей по другому полю? Покажите мне, где можно увидеть такое в действии.

Да и «самое простое» я не понял. Зачем там вообще вложенный запрос, если в ORDER BY можно сколько угодно полей вставить?

 

[Сергей Тарасов]

Автор оригинала: baev
Не понял: отсортировать уже выбранные 100 записей по другому полю? Покажите мне, где можно увидеть такое в действии.

Это довльно частный случай, но все же... Смотри... Есть, к примеру, кампании: таблица firms.
Есть поле rating, к примеру, и поле title. Нужно выбрать топ-100 фирм с самым большим рейтингом, и потом отсортировать их по названию....

Будет что-то вроде

SELECT * FROM (SELECT * FROM `firms` ORDER BY `rating` DESC LIMIT 0, 100) AS tbl ORDER BY `tbl`.`title`;

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

 

[Gas]

При таком объёме данных (LIMIT 100) - filesort должен быть в памяти и без особых тормозов.

 

[baev]

Нужно выбрать топ-100 фирм с самым большим рейтингом, и потом отсортировать их по названию....

И?
Вы на второй вопрос не ответили:

Зачем там вообще вложенный запрос, если в ORDER BY можно сколько угодно полей вставить?

 

[phprus]

baev

И?

Имеется ввиду, что надо выбрать 100 фирм по рейтингу, а потом забыть про то, что мы сортировали их по рейтингу и отсортировать только эти 100 записей по имени. Тут одним ORDER BY обойтись помоему никак нельзя.

 

[crocodile2u]

[sql]select * from (SELECT publish_date, title from article ORDER BY publish_date DESC LIMIT 10) AS a ORDER BY title;[/sql]

вот что-то подобное не пойдет? выбираем 10 последних (по дате) статей и сортируем их по названию...

 

[Gas]

crocodile2u
уже

 

[phprus]

crocodile2u
Так Сергей Тарасов привел пример такого-же запроса. Тут речь идет о том, что внешний SELECT при сортировке не будет использовать индексы и о том, можно ли этого избежать.

 

[Gas]

можно ли этого избежать

Скорее всего не получится. Но, как я уже говорил, отсортировать 100 записей без индексов и ещё если сделать ORDER BY LEFT(title,2) должно быть очень быстро.

 

[phprus]

Gas

Скорее всего не получится.

Я тоже так думаю, но вопрос в этой теме стоит почти такой, как я написал.

 

[Breeze]

будет ли в большинстве случаев MySQL использовать индексы для таблицы, в которой 50-100 записей и все записи попадают в выборку?

 

[Gas]

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

 

[Breeze]

Это я к тому, что гораздо важнее чтобы внутренний select был оптимизирован по самый небалуйся..
а внешний работает фактически с копией данных, для которых нет индекса.. но для 100 записей это и не нужно, учитывая мускулевский кэш, если запрос выполняется не раз в час..

Все это разумеется ИМХО и из области предположений :о)

 

[Gas]

гораздо важнее чтобы внутренний select был оптимизирован

дык тут вроде все приняли это за аксиому (я точно)

 

[Breeze]

да, но словами не зафиксировали

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

 

[Сергей Тарасов]

Итак, можно было бы подытожить, что более оптимального способа пока нет. А жаль... Это относится кстати к пересортировке некого SELECT (уже выборке)...

-~{}~ 08.12.07 21:50:

Интересно, кстати, было бы услышать мнения спецов по MySQL.
Что они думают по этому поводу?..

 

[Mr_Max]

Breeze

будет ли в большинстве случаев MySQL использовать индексы для таблицы, в которой 50-100 записей и все записи попадают в выборку?

нет. И в большинстве и в меньшинстве случаев.

 

[Breeze]

нет. И в большинстве и в меньшинстве случаев.

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

ЗЫ: в меньшинстве случаев -- будет, не зря я про большинство упомянул

 

[Сергей Тарасов]

Автор оригинала: Mr_Max
Breeze

нет. И в большинстве и в меньшинстве случаев.

Хм... А это откуда следует?