Comments 9
Зачёт статейка. Теперь люди научатся работать с фильтрацией.
Каков размер таблицы в количестве строк и МБ? Какова нагрузка на запись и чтение в отдельности на данную таблицу в секунду?
Как правило, в подобных системах таблицы не суперактивны - это не логи все-таки, а результаты каких-то пользовательских действий, которых не может быть "бесконечно много".
Сотни тысяч / миллионы записей в таких таблицах обычно. Если бизнес крупный и существующий долго - сотни миллионов, но все равно единицы TPS.
выборка по sale_id + sale_dt, не имеет смысла потому что sale_id - первичный ключ, там значения не повторяются + они упорядочены
Почему бы для пагинации не использовать WHERE sale_id > *последнее значение id продажи* ?
Для дополнительной дофильтрации по другим полям можно добавить расширенную статистику и/или составные индексы по нескольким полям
Правильно,
sale_id- уникальный ключ (поскольку PK), поэтому(sale_dt, sale_id)- тоже уникальный ключ, который позволяет вычитывать блок записей, без оглядки на сайд-эффекты возможной неуникальности ключа.Потому что никто не гарантирует монотонного возрастания
sale_dtвместе сsale_id. Наоборот, в учетных системах регулярно возникает задача отразить что-то "задним числом", завести документ за прошлую дату.Как составной индекс поможет при фильтрации по полю из связанной таблицы конкретно в приведенном примере?
Но в таком случае мы рискуем получить‑таки все эти 1000 записей (если фильтр оказался не такой уж редкий) с необходимостью сразу отрисовать в интерфейсе — а это долго!
Не уловил, откуда возникла ситуация, что полученные в БЛ записи нужно обязательно отрисовать? Получили от клиента запрос на 25 записей - вот они, получите, распишитесь. А 975 остались лежать в кэше до лучших времён.
Да и ограничение на время работы выборки тоже можно применить в последовательном переборе.
Ну, как-то странно уже получить из базы 1000 записей, а вернуть клиенту только 25 из них - зачем тогда сразу читать в разы больше? А если клиент хотел всего 25 - зачем мы стали столько читать?
"Последовательный перебор" - это как, через JOIN?
Клиент попросил 25 записей. БЛ вернул 1000. БЛ тупой, запросов не понимает?
Клиенту пришло 1000 записей. Клиенту по дизайну нужно отрисовать 25. Клиент тупой, не может прихранить в памяти остальные записи, чтобы потом их отрисовать, не запрашивая лишний раз БЛ?
"Последовательный перебор" - я имел в виду способ, описанный в статье под словами "То есть отрисовка реестра в такой модели выглядит примерно так:". Там можно встроить таймаут на работу алгоритма, и получите примерно такой же результат.
Если клиенту пришло 1000 записей, хотя по дизайну надо всего 25 для отрисовки - то зачем мы грузили БД начиткой лишних, если в 90% случаев пользователь все равно не прокрутит дальше первого экрана?
Да и ограничение на время работы выборки тоже можно применить в последовательном переборе.
Как правило, при таком "обычном" переборе и так не возникает проблем со временем исполнения запроса - они достаточно быстры. Просто их приходится делать очень много, чтобы нарисовать хоть что-то.
Приведенный способ как раз и позволяет сократить их количество, заодно сократив непроизводительные затраты каждой итерации.
SQL HowTo: крупицы золота в реестре