Да.Высокие смещения медленные и неэффективные.
Единственный способ найти записи со смещением - это вычислить все записи, которые были до этого, а затем отбросить их.
(я не знаю ROW_NUMBER (), но в стандартном SQL будет LIMIT. Так
SELECT * FROM table LIMIT 1999,20
)
.. в приведенном выше примере первые 2000 записейсначала нужно получить, а затем выбросить .Как правило, он не может быть пропущен вперед или использовать индексы для перехода к правильному расположению в данных, потому что обычно существует предложение «ГДЕ», фильтрующее результаты.
Возможно кэшировать результаты, что, вероятно, и делает SO.Так что на самом деле не нужно вычислять большие смещения каждый раз.(Большинство запросов SO представляют собой «небольшой» набор известных тегов, поэтому его вполне можно кэшировать. Произвольный поисковый запрос будет иметь много версий для перехвата, что делает его непрактичным) (В качестве альтернативы может использоваться другая реализация, которая позволяетпроизвольные смещения)
Другие места, имеющие отношение к подобным вещам http://sphinxsearch.com/docs/current.html#conf-max-matches
Задняя часть теста envolope:
mysql> select gridimage_id from gridimage_search where moderation_status = "geograph" order by imagetaken limit 100999,3;
...
3 rows in set (11.32 sec)
mysql> select gridimage_id from gridimage_search where moderation_status = "geograph" order by imagetaken limit 3;
...
3 rows in set (4.59 sec)
(Произвольный запрос выбирается так, чтобы не использовать индексы оченьхорошо, если индексы можно использовать, разница менее выражена и труднее увидеть. Но в производственной системе, выполняющей много запросов, разница в 1 или 2 мс огромна)
Обновление: (для отображения индексированного запроса)
mysql> select gridimage_id from gridimage_search order by imagetaken limit 10;
...
10 rows in set (0.00 sec)
mysql> select gridimage_id from gridimage_search order by imagetaken limit 100000,10;
...
10 rows in set (1.70 sec)