My<cod/>.net
Почему пагинация так ресурсоемка?
Это одна из тех вещей, которые, кажется, имеют странную кривую, где чем больше я думаю об этом, тем больше это имеет смысл. В определенной степени, конечно. И тогда для меня это вообще не имеет смысла.
Не хочешь просветить меня?
Потому что в большинстве случаев вы должны сначала отсортировать свои результаты. Например, при поиске в Google можно просмотреть только до 100 страниц результатов . Они не утруждают себя сортировкой по рангу страницы за пределами 1000 веб-сайтов для данного ключевого слова (или комбинации ключевых слов).
Разбиение на страницы происходит быстро. Сортировка идет медленно.
Любос прав, проблема заключается не в том, что вы подкачиваете (что занимает HUGE количество данных с провода), а в том, что вам нужно выяснить, что на самом деле происходит на странице..
Тот факт, что вам нужно страницу подразумевает, что есть много данных. Сортировка большого количества данных занимает много времени :)
Этот вопрос кажется довольно хорошо освещенным, но я добавлю немного MySQL конкретного, поскольку он ловит много людей:
Избегайте использования SQL_CALC_FOUND_ROWS . Если набор данных не является тривиальным, подсчет совпадений и получение x-количества совпадений в двух отдельных запросах будет намного быстрее. (Если это тривиально, вы едва заметите разницу в любом случае.)
Я думал, Вы имеете в виду разбиение на страницы печатной страницы - Вот где я порезал зубы. Я собирался ввести отличный монолог о сборе всего контента для страницы, позиционировании (здесь огромное количество правил, движки constrait весьма полезны) и обосновании... но, видимо, вы говорили о процессе организации информации на веб-страницах.
Для этого я бы предположил, что база данных попадает. Доступ к диску осуществляется медленно. Как только вы получите его в памяти, сортировка будет дешевой.
Конечно, сортировка по случайному запросу занимает некоторое время, но если у вас возникли проблемы с регулярным использованием одного и того же разбитого на страницы запроса, либо что-то не так с настройкой базы данных (неправильное индексирование/вообще нет, слишком мало памяти и т. д. Я не менеджер БД) или вы делаете разбиение на страницы серьезно неправильно:
Ужасно неправильно: например, делая select * from hugetable where somecondition; в массив, получая счетчик страниц с помощью array.length, выберите соответствующие индексы и dicard массив, а затем повторите это для каждой страницы... Это то, что я называю серьезно неправильным.
Лучшее решение два запроса: один получает только счет, а другой получает результаты с помощью limit и offset . (Некоторые проприетарные, нестандартные-sql сервер может иметь один вариант запроса, я не знаю)
Плохое решение может на самом деле работать довольно хорошо в небольших таблицах (на самом деле это не немыслимо, что это быстрее на очень маленьких таблицах, потому что накладные расходы на создание двух запросов больше, чем получение всех строк в одном запросе. Я не говорю, что это так...) но как только база данных начинает расти, проблемы становятся очевидными.