Почему пагинация настолько ресурсозатратна?

Question

Это одна из тех вещей, которая, кажется, имеет странную кривую: чем больше я об этом думаю, тем больше в ней смысла.В определенной степени, конечно.И тогда для меня это вообще не имеет смысла.

Хотите просветить меня?

Answer 1

Потому что в большинстве случаев вам сначала нужно отсортировать результаты.Например, когда вы ищете в Google, вы можете просмотреть только до 100 страниц результатов.Они не утруждают себя сортировкой по рейтингу страниц за пределами 1000 веб-сайтов по заданному ключевому слову (или комбинации ключевых слов).

Пагинация быстрая.Сортировка идет медленно.

Answer 2

Любош верно, проблема не в том, что вы выполняете пейджинг (который забирает ОГРОМНЫЙ объем данных по сети), а в том, что вам нужно выяснить, что на самом деле происходит на странице..

Тот факт, что вам нужно перелистывать страницы, означает, что данных много.Для сортировки большого количества данных требуется много времени :)

Answer 3

Это действительно расплывчатый вопрос.Нам понадобится конкретный пример, чтобы лучше понять проблему.

Answer 4

Этот вопрос кажется довольно хорошо освещенным, но я добавлю кое-что, специфичное для MySQL, поскольку оно привлекает многих людей:

Избегать использования SQL_CALC_FOUND_ROWS.Если набор данных не тривиален, подсчет совпадений и получение x количества совпадений в двух отдельных запросах будет намного быстрее.(Если оно является тривиально, в любом случае вы едва заметите разницу.)

Answer 5

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

Для этого я бы предположил попадания в базу данных.Доступ к диску медленный.Как только вы запомните это в памяти, сортировка станет дешевой.

Answer 6

Конечно, сортировка случайного запроса занимает некоторое время, но если у вас возникают проблемы с регулярным использованием одного и того же запроса с разбиением на страницы, то либо что-то не так с настройкой базы данных (неправильная индексация/отсутствие вообще, слишком мало памяти и т. д.).Я не менеджер БД) или вы серьезно неправильно разбиваете страницы:

Ужасно неправильно:напримерделает select * from hugetable where somecondition; в массив, получая количество страниц с помощью array.length, выберите соответствующие индексы и удалите массив, а затем повторите это для каждой страницы...Это то, что я называю серьезной ошибкой.

Лучшее решение двух запросов:один получает только подсчет, а другой получает результаты, используя limit и offset.(Некоторые проприетарные, нестандартные серверы SQL могут иметь один вариант запроса, я не знаю)

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