30.2. Планы выполнения запросов. Физические соединения: nested loop, merge join, hash join. Индексы
Vložit
- čas přidán 26. 03. 2021
- 🪂Ссылка на статью "Как работает реляционная БД":
habr.com/ru/company/mailru/bl...
🪂Ссылка на статью "Порядок выполнения запроса SELECT и план запроса в MS SQL Server":
habr.com/ru/company/otus/blog...
🪂Ссылка на pdf файл с презентацией по уроку 30:
github.com/Data-Learn/SQL-for...
🪂Ссылка на SQL код из урока 30:
raw.githubusercontent.com/Dat...
Крутий курс! Подяка автору за роботу і зусилля!
Спасибо за замечательный курс! Буду рекомендовать.
Не смотря на качество звука его можно подрихтовать методом расширений в браузере (эквалайзер), убавив шум, повысив четкость, громкость и т.д. (хотя толку об этом писать в конце курса :D)
Обучаюсь на аналитика.
Первые 2 модуля в связке с 1-м уроком 3-го модуля (оконные функции) были самыми необходимыми и полезными для меня.
Жаль что данный курс не имеет особого спроса, он вмещает в себе всё, что необходимо знать как минимум начинающему специалисту, практики уйма.
Связка "теория + практика одновременно" это то, что присуще этому курсу, и это безусловно один из лучших подходов в обучении.
Анатолий, большое спасибо за ваш труд! Курс очень понравился!
Спасибо за курс!
Cпасибо большое за курс, будет ли заключительное видео в котором расскажете в каком направлнии двигаться дальше?
В середине видео гдето с 29:38 звук начал отставать от видео где то вообще на секунд 10, очень чувствуется, в частности с 32:07 :( проверил и видимо ближе к концу пофиксилось, но сколько то времени точно такой существенный баг длится
В целом неплохо, но нужно упомянуть, что на продуктивной базе вслепую создавать некластерные индексы ввиду того, что оптимизатор их предлагает при анализе конкретных запросов - не самая лучшая идея - такие вещи надо всегда смотреть в комплексе, как-бы учитывать, что есть возможность где-то улучшить, а где-то - навредить. Поэтому в параллель надо анализировать и нагрузку на таблицу (для которой создается вспомогательный некластерный индекс), особенно в историческом разрезе - применять дополнительные админские скрипты для целей всестороннего анализа, которые, к примеру, показывают I/O нагрузку за период времени, кол-ва операций чтений, записи, профайлером помониторить денек-другой; так же необходимо проговаривать с пользователями бизнес-системы системы и прикладными разработчиками, прежде чем создавать.
Так как оптимизируя чтение (созданием доп. индекса) - мы и утяжеляем последующие операции вставки/обновления, что может быть критично, если таблица чаще пишется, чем читается.
Ну такие тонкости, в общем, но крайне важные при эксплуатации.
... замечание почти снято - под самый конец чуть упомянул всё же :)
А можно узнать почему удалили мой коммент с этого видео и с 30.1 где я полезные ссылки в дополнение к видео оставил? Даже видно что счетчик комментов на 1 меньше чем их на самом деле)