Комментарии 4
Часть с индексами ВСЁ испортила.
Без неё претензии были скорее к стилю изложения. Видно, что сочинения автор в школе писал на троечку, и с тех пор ни одной книжки не прочитал. А просмотр тиктоков почему-то стиль письма и связность речи не улучшает.
Но на фоне части про индексы это всё меркнет.
"Создадим индексы по всем этим полям" — вот вы это серьёзно? После собственного же утверждения строчкой выше, что нельзя создавать кучу индексов наобум, просто "щоб було"?
Такое ощущение, что вы сами не поняли, что сделали, и "вопросы на подумать" задаёте читателям. Чтобы они вам объяснили, какой индекс в итоге сработал, и как именно.
Но у читателей наоборот, возникают свои вопросы.
Какой индекс в итоге сработал?
Какие поля к нему можно добавить, чтобы запрос работал еще быстрее?
Какие индексы не имеют отношения к запросу?
Почему добавление индекса по category_id — плохая идея, и как можно было сделать лучше?
Зачем вообще может понадобиться индекс по place_id?
Объективности ради, первые две части полезные. Только сравнивать методы пагинации на датасете в 1000 строк — это смешно. Было бы их хотя бы 100 000 — вот тут разница будет заметна невооруженным глазом.
Курсорная пагинация показывает лучшие результаты, так как в запросе выбираются 200 элементов, в то время, как в пагинации смещением, выбираются 1200 элементов и 1000 отбрасываются.
Не корректно сравнивать, что бы при курсорной пагинации попасть к 1000 странице придётся сделать сначала пять выборок по 200.
При курсорной мы не можем сразу к 1000 записи перейти, нам надо долистать до неё.
При страничной - можем.
И в этом их разница, страничная для доступа через случайное чтение, курсорная для доступа через страничное чтение.
Страничная что бы по записям бегать туда и обратно, курсорная строго для промотки дальше, ещё и пользовательский интерфейс будет перегружен длиннющим списком.
Оптимизация бэкенда приложения с примерами на Symfony. Часть 1