Насколько допустимы запросы без LIMIT?

Question

[Владимир]

Есть ли где-нибудь внятное объяснение, good/bad practice по поводу запросов без лимитов?

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

А еще, для наглядности, как повесить сервер если я знаю URL который выдает без LIMIT данные размером в 10x MB на клиент?

Answer 1

[Марат]

Плюсы использования limit:
1) Ограничение и предсказуемость кол-во результирующих строк со стороны сервера,
2) Меньше нагрузка на сеть,
3) Проще проектировать GUI выдавая результат запроса "пачками" с определенным количеством строк.
4) Подсказка для оптимизатора запросов, что приведет к увеличению производительности выборки со стороны сервера

Минусы использования limit:
1) Можно сломать логику и/или пропустить ошибку. Допустим в таблице справочника отсутствует primary key и задублировалась запись. Применяя выборки с limit 1 - не поймаете данную ошибку.
2) Отсутствует в стандарте SQL до 2011.
3) Не стандартизирован в SQL92. Многие СУБД имеют аналоги (top - MSSQL, Offset - вроде в Postgres; или, еще хуже - конструкции с where rownum = в Oracle ). То есть меняя версию СУБД Вам, возможно, придется переписать все подобного рода запросы.

P.S. Такого рода споры о целесообразности применения конструкций СУБД необходимо решать с 2х точек зрения СУБД и Приложения. Уверены, что у Вас 99.999999% нет ошибок в реализации объектов СУБД и не планируете переходить на другие СУБД - применяйте limit, иначе задумайтесь.
P.S.S. Аналогичен спор и о необходимости Order by. Серверные люди скажут, что order by - баловство, не стоит нагружать сервер задачами сортировки полученных данных - это "крестьянское" дело должно ложиться на плечи приложения :)

Answer 2

[Андрей]

практика - все от данных зависит. где-то надо лимитировать, где-то смысла в этом нет.
как повесить - просто запросите эту страницу с данными много-много раз

Answer 3

[FiFaGeFa]

Без очень конкретного описания говорить не о чем.
Можно и не лимитировать.
Есть и такие системы, которые не позволяют уйти в перерасход памяти, даже если программист тупой.
Но в целом, да, лимитировать нужно. Если вы не уверены, что можно не лимитировать.

Answer 4

[Алексей Скобкин]

Руководствуйтесь здравым смыслом. Когда у вас, например, выборка по Primary Key, то вам LIMIT не нужен, т.к. у вас вернётся одна запись, либо, если вы выбираете по вхождению, то максимальное число записей вам известно заранее.
Если же вы делаете выборку из большого объёма данных (таблица с 10 миллионами записей), то логично делать LIMIT до того количества, которое вам нужно. А если нужно обработать всё - часто лучше обрабатывать записи "пачками" запрашивая их по 10/50/100/... делая сдвиг по списку.
Странный вопрос, в общем.

А то встречаются люди

Люди и не такое могут. Зачем глупости за ними повторять?

Answer 5

[Владимир]

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

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

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

Answer 6

[Денис К]

Лимитирую все запросы, количество результатов которых точно знаю.

Например подаю на выборку товары по фильтру, где кроме прочего есть ограничение по идентификаторам, такой каскадный фильтр. Отсюда знаю, что больше чем подал идентификаторов на вход в выборке не будет только меньше или равно, вот и проставляю limit. Одиночные выборки в обязательном порядке с limit 1.