| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > насколько длинный запрос может быть |
| Автор: bars80080 14.12.2010, 16:29 | ||
вот есть, к примеру такой запрос:
со временем из-за перечисления идентификаторов он может серьёзно вырасти в длине. насколько длинным позволяется быть запросу? |
| Автор: triclosan 14.12.2010, 16:36 |
| для оператора IN - 1000 шт |
| Автор: Akina 14.12.2010, 16:46 |
| LIMIT 0, 40 тоже будет меняться? |
| Автор: bars80080 14.12.2010, 17:05 |
в пределах 10 - 50 Добавлено через 1 минуту и 40 секунд думаете стоит задумать механизм нарезки? чтобы в IN (...) шли только на необходимые номера? |
| Автор: Akina 14.12.2010, 17:13 | ||
Несомненно! |
| Автор: bars80080 14.12.2010, 17:25 |
| ок |
| Автор: Akina 14.12.2010, 17:30 |
| Впрочем, всё зависит от того, как и откуда получается этот список. Если он тянется с сервера предыдущим запросом - то надо думать, нет ли возможности остаться на сервере и не переть их на клиента, а если формируется локально, пусть и программно. пусть и на базе результата предыдущего запроса, и эта логика не выбрасывается на сервер - то, конечно, есть великий смысл отправлять серверу на исполнение список только нужных ИДов. |
| Автор: bars80080 14.12.2010, 20:19 |
| это поиск. пользователь набирает в форме некоторую комбинацию полей фильтрации и сортировки, отправляет на сервер, по базе находятся записи удовлетворяющие условию. и тут возникает момент, что записей может быть несколько сотен, а то и тысяч, выводить их все сразу на страницу - не резон. с другой стороны поиск в таблице на миллион записей (ориентировочное число) при кудрявых условиях (возможно будут всякие LIKE, но это уже другая история) затребует существенных ресурсов от процессора и времени. тогда мы записываем в специальную таблицу результат выборки (список идентификаторов), и перекидываем пользователя на просмотр результатов. дальше он просто ходит по готовому списку |