Подготовка к собесу - Подзапросы SQL и оптимизация

Поділитися
Вставка
  • Опубліковано 26 лис 2024

КОМЕНТАРІ • 5

  • @Antoniolavoisier1
    @Antoniolavoisier1 27 днів тому

    годный контент, спасибо

  • @nikolaykozlov4888
    @nikolaykozlov4888 2 місяці тому +4

    Огонь, то что нужно

  • @evgeny3148
    @evgeny3148 Місяць тому +1

    Спасибо за материал, жду новых видосов. Подача - огонь

  • @shamil4837
    @shamil4837 2 місяці тому +3

    Лайк за контент, продолжайте!:)

  • @HideDJeker
    @HideDJeker Місяць тому

    Не уверен что есть смысл рассматривать условия с limit - под такие запросы субд не рассчитывались из за своей специфики, это я пытаюсь надумать почему в целом то оптимизатору пофиг на эти лимиты, но главное что они могут спутать с самого важного - порой оптимизации заключаются в поиске преобразования к неэквивалентному плану, к которому ни один оптимизатор не приведет, но может вам и хотелось такое преобразование или именно для вашего кейса это считается эквивалентным, самое понятное a.* from a left join b - может дать дубли, * from a where exists (...b) - не может дать дубли, эти два запроса неэквивалнетны из за дублей, но бизнесово наверное мы все таки хотели второе) но ни один оптимизатор такого не допустит. (Может быть всякие relation и должны в некоторых кейсах гарантировать что дублирования не должно быть, но на деле таких чудес не видел). На деле найти кейсы что оптимизатор не справился, а мы такие умные нашли эквивалентный запрос который эффективнее - очень сложно, и в 99% речь идет или о неэквивалентном преобразовании или о малом баге - так в psql очень все грустно со сменой порядка join из подзапроса на запрос
    скалярные подзапросы это зло, которые еще и ломают текстовый план из-за "цикличности"