Почему нумерация ресурсов такая дорогая?

Question

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

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

Answer 1

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

Нумерация страниц выполняется быстро. Сортировка медленная.

Answer 2

Lubos прав, проблема не в том, что вы выполняете пейджинг (который отнимает ОГРОМНОЕ количество данных), а в том, что вам нужно выяснить, что на самом деле происходит на странице ..

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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