Почему разбиение на страницы так дорого обходится?
Это одна из тех вещей, которые кажутся странными: чем больше я думаю об этом, тем больше в них смысла. В определенной степени, конечно. И тогда это вообще не имеет для меня смысла.
Хотите просветить меня?
Ответы 6
Потому что в большинстве случаев сначала нужно отсортировать результаты. Например, при поиске в Google вы можете просмотреть не более 100 страниц результатов. Они не заботятся о сортировке по рейтингу страниц за пределами 1000 веб-сайтов по заданному ключевому слову (или комбинации ключевых слов).
Пагинация выполняется быстро. Сортировка идет медленно.
Это действительно расплывчатый вопрос. Нам понадобится конкретный пример, чтобы лучше понять проблему.
Любош прав, проблема не в том, что вы выполняете пейджинг (который забирает ОГРОМНЫЙ объем данных по сети), а в том, что вам нужно выяснить, что на самом деле происходит на странице ..
Тот факт, что вам нужно пейджинговать, подразумевает, что данных много. На сортировку большого количества данных уходит много времени :)
Я думал, вы имели в виду пагинация напечатанной страницы - вот где я порезался. Я собирался ввести отличный монолог о сборе всего контента для страницы, позиционировании (огромное количество правил здесь, механизмы constrait весьма полезны) и обосновании ... но, видимо, вы говорили о процессе организации информации на веб-страницах .
Для этого я бы предположил попадания в базу данных. Доступ к диску медленный. Как только вы запомните его, сортировка обходится дешево.
Конечно, сортировка случайного запроса занимает некоторое время, но если у вас возникают проблемы с тем же запросом с разбивкой на страницы, который используется регулярно, либо что-то не так с настройкой базы данных (неправильная индексация / отсутствие вообще, слишком мало памяти и т. д. I ''). m не db-manager) или вы серьезно ошибаетесь при разбивке на страницы:
Ужасно неправильно: например, выполнение select * from hugetable where somecondition; в массиве, получение счетчика страниц с помощью array.length, выбирает соответствующие индексы и задает массив - затем повторяет это для каждой страницы ... Это то, что я называю серьезно неправильным.
Лучшее решение - два запроса: один получает только счет, а другой - результаты с использованием limit и offset. (Некоторые проприетарные нестандартные sql-серверы могут иметь один вариант запроса, я не знаю)
Плохое решение может на самом деле вполне нормально работать с небольшими таблицами (на самом деле немыслимо, что это быстрее на очень маленьких таблицах, потому что накладные расходы на выполнение двух запросов больше, чем получение всех строк в одном запросе. Я не говорю, что является так что ...) но как только база данных начинает расти, проблемы становятся очевидными.
Комбинация LIMIT с большим смещением и ORDER BY или GROUP BY по-прежнему может быть очень ресурсоемкой, поэтому Google не получает полного подсчета (всего более 1000 результатов, и это «оценка») и не разбивает на страницы больше первые 1000 результатов.
Этот вопрос кажется довольно хорошо освещенным, но я добавлю кое-что, относящееся к MySQL, поскольку он привлекает множество людей:
Избегайте использования SQL_CALC_FOUND_ROWS. Если набор данных не является тривиальным, подсчет совпадений и получение x совпадений в двух отдельных запросах будет намного быстрее. (Если это является тривиально, вы вряд ли заметите разницу.)
Случайный просмотр SO после ужина, интригующий совет, 10-минутный тест, а затем 10-минутная настройка, и вуаля, моя база данных уменьшена вдвое на моем самом тяжелом сайте! Спасибо!
Это хороший совет. Выполнение подсчета в другом запросе может подсчитывать без извлечения данных строки и может использовать только индексы. Однако работает ли это в InnoDb так же хорошо, как в MyIsam? У меня странное ощущение, что все по-другому, но могу ошибаться.
Если вы посмотрите на заголовок, вопрос становится понятным, когда вы читаете сам вопрос, он перестает иметь смысл.