ДО
ну тут про 16 запросов речь идет. Что там у вас хибер с бд делает?)
там ещё связанная таблица есть 1к N
Size: a a a
2020 July 02
ДО
15 записей тянутся и для каждого ещё дозапрос на связанную таблицу
A
Добрый вечер, не подскажите хороших туториалов по спрингу?
Поищи в этлм чате, тьма хороший ответов
ДО
15 записей тянутся и для каждого ещё дозапрос на связанную таблицу
Но они не влияют, я время замерял ещё до того, как они вызываются
D𝔇
15 записей тянутся и для каждого ещё дозапрос на связанную таблицу
ну если там тоже фулсканы, то отсюда и 38секунд
ДО
ну если там тоже фулсканы, то отсюда и 38секунд
Не, если я связь уберу, то всё-равно то же самое
A
ну если там тоже фулсканы, то отсюда и 38секунд
Больше 2кк, оптимизатор некоторых баз может легко предпочесть фулскан индексу, там уже без партиционированного индекса смысла нет еще и по индексу ползать.
A
Не, если я связь уберу, то всё-равно то же самое
А какая СУБД?
ДО
Anton
А какая СУБД?
MS SQL 2014
D𝔇
Anton
Больше 2кк, оптимизатор некоторых баз может легко предпочесть фулскан индексу, там уже без партиционированного индекса смысла нет еще и по индексу ползать.
Скорее наоборот - на маленьких таблицах даже при индексах чаще всего будут фулсканы. А на больших фулскан вместо скана по индексу будет в случае если например в таблице подавляющее большинство записей не попадает под условие(или субд так думает из-за неактуальной статистики).
Но опять же это не относится к сортировке, только к выборке
Но опять же это не относится к сортировке, только к выборке
ДО
D𝔇
а в логах хибера вот тот самый запрос, который выполняется 15 секунд?
ДО
а в логах хибера вот тот самый запрос, который выполняется 15 секунд?
Да
ДО
Ну вот есть какая инфа, это может быть всё из-за сущностей
A
Скорее наоборот - на маленьких таблицах даже при индексах чаще всего будут фулсканы. А на больших фулскан вместо скана по индексу будет в случае если например в таблице подавляющее большинство записей не попадает под условие(или субд так думает из-за неактуальной статистики).
Но опять же это не относится к сортировке, только к выборке
Но опять же это не относится к сортировке, только к выборке
Расскажите это оптимизатору Oracle DB, сам раньше не понимал, пока не прочувствовал)
Прямой индекс, подходящий запросу вполне может игнорировать, с самой актуальной статистикой. И если его заставить хинтами, действительно по индексу медленнее, потому что поиск в индексе и мерж с индексом жрет больше сортировки фулсканом, и кеши с индексом могут больше нагружаться.
Прямой индекс, подходящий запросу вполне может игнорировать, с самой актуальной статистикой. И если его заставить хинтами, действительно по индексу медленнее, потому что поиск в индексе и мерж с индексом жрет больше сортировки фулсканом, и кеши с индексом могут больше нагружаться.
ДО
У меня всё-равно read-only
ДО
У меня всё-равно read-only
Переделать на dto норм тема
ДО
Однако я хотел заюзать setResultTransformer, но он блин deprecated
D𝔇
Anton
Расскажите это оптимизатору Oracle DB, сам раньше не понимал, пока не прочувствовал)
Прямой индекс, подходящий запросу вполне может игнорировать, с самой актуальной статистикой. И если его заставить хинтами, действительно по индексу медленнее, потому что поиск в индексе и мерж с индексом жрет больше сортировки фулсканом, и кеши с индексом могут больше нагружаться.
Прямой индекс, подходящий запросу вполне может игнорировать, с самой актуальной статистикой. И если его заставить хинтами, действительно по индексу медленнее, потому что поиск в индексе и мерж с индексом жрет больше сортировки фулсканом, и кеши с индексом могут больше нагружаться.
Это какие-то специфические случаи. Возможно большая выборка
A
Это какие-то специфические случаи. Возможно большая выборка
Да, именно для больших выборок