у нас есть пагинация и какая-то фильтрация: товары по categoryId. Когда начинает тормозить offset? До или после выборки?
Виляют ли на него какие-то данные, которые не попадают в условие where?
Читал на форумах, что offset начинает тормозить где-то на 100 000. В реалиях БД это невероятно мало, а в реалиях сайта, допустим новостной ленты, сложно представляется, что там offset хотя бы до 10 000 дойдёт, так как фильтрация сильно сужает диапазон данных, по которым будет работать offset
Или я что-то банальное упускаю?
такого рода пагинация невозможна без сортировки если сортировка совпадает с сортировкой индекса - все в порядке, нечему тормозить если не совпадает - тормозить будет сортировка
это от запроса зависит
Например? (я просто даже не знаю, как правильно вопрос в гугле или chatgpt сформулировать)
Что-то я запутался. Сортировка с сортировкой индекса? Чего?
если будете выбирать по primary key, то офссет не будет тормозить
совападает, если вы сделали индекс по полю, по которому делаете orderBy
Без сортировки у вас порядок выдачи не детерминирован Фактически - случайная выборка с первой страницы
На цене товара весит индекс, а это значит, что товар для выборки уже отсортирован (и это, наверное, сильно сбивает меня с толку)
Ну поглядите на explain
Почему не значит? Если там висит индекс, то для выборки будет выполняться бинарный поиск, а для этого данные должны быть отсортированы
Потому что сортировка в SQL - это ORDER BY. Без него порядок записей не определённый
Ну.. я немного не это имел ввиду, но ладно)
или фуллскан, если планировщик не придумает, как индекс задействовать
Обсуждают сегодня