30.2. Планы выполнения запросов. Физические соединения: nested loop, merge join, hash join. Индексы

🪂Ссылка на статью "Как работает реляционная БД":

🪂Ссылка на статью "Порядок выполнения запроса SELECT и план запроса в MS SQL Server":

🪂Ссылка на pdf файл с презентацией по уроку 30:

🪂Ссылка на SQL код из урока 30:

[Hamerace]

Крутий курс! Подяка автору за роботу і зусилля!

[SeReGa]

Анатолий, большое спасибо за ваш труд! Курс очень понравился!

[dgrey.]

Спасибо за замечательный курс! Буду рекомендовать.
Не смотря на качество звука его можно подрихтовать методом расширений в браузере (эквалайзер), убавив шум, повысив четкость, громкость и т.д. (хотя толку об этом писать в конце курса :D)

Обучаюсь на аналитика.
Первые 2 модуля в связке с 1-м уроком 3-го модуля (оконные функции) были самыми необходимыми и полезными для меня.
Жаль что данный курс не имеет особого спроса, он вмещает в себе всё, что необходимо знать как минимум начинающему специалисту, практики уйма.
Связка "теория + практика одновременно" это то, что присуще этому курсу, и это безусловно один из лучших подходов в обучении.

[victorguschenko]

Cпасибо большое за курс, будет ли заключительное видео в котором расскажете в каком направлнии двигаться дальше?

[dpolovinkin]

В середине видео гдето с 29:38 звук начал отставать от видео где то вообще на секунд 10, очень чувствуется, в частности с 32:07 :( проверил и видимо ближе к концу пофиксилось, но сколько то времени точно такой существенный баг длится

[MVOralov]

В целом неплохо, но нужно упомянуть, что на продуктивной базе вслепую создавать некластерные индексы ввиду того, что оптимизатор их предлагает при анализе конкретных запросов - не самая лучшая идея - такие вещи надо всегда смотреть в комплексе, как-бы учитывать, что есть возможность где-то улучшить, а где-то - навредить. Поэтому в параллель надо анализировать и нагрузку на таблицу (для которой создается вспомогательный некластерный индекс), особенно в историческом разрезе - применять дополнительные админские скрипты для целей всестороннего анализа, которые, к примеру, показывают I/O нагрузку за период времени, кол-ва операций чтений, записи, профайлером помониторить денек-другой; так же необходимо проговаривать с пользователями бизнес-системы системы и прикладными разработчиками, прежде чем создавать.
Так как оптимизируя чтение (созданием доп. индекса) - мы и утяжеляем последующие операции вставки/обновления, что может быть критично, если таблица чаще пишется, чем читается.
Ну такие тонкости, в общем, но крайне важные при эксплуатации.

[dpolovinkin]

А можно узнать почему удалили мой коммент с этого видео и с 30.1 где я полезные ссылки в дополнение к видео оставил? Даже видно что счетчик комментов на 1 меньше чем их на самом деле)