Недавно, присутствуя на сессии саммита PASS, посвященного оптимизатору запросов, мне был задан вопрос о том, как рассчитываются оценки стоимости затрат процессора (Estimated CPU cost) и затрат на ввод-вывод (Estimated I/O cost), т.е. откуда берется конкретное значение, скажем, 1,13256. В тот момент я мог ответить только то, что Майкрософт не публикует, как рассчитывается стоимость. Продолжить чтение "Введение в оценку стоимости плана"
Оконные функции упрощают написание многих запросов и зачастую обеспечивают лучшую производительность по сравнению со старыми методами. Например, использование функции LAG существенно лучше, чем применение самосоединения. Однако чтобы добиться лучшей производительности в целом, необходимо понимать концепции оконных функций, и то как они используют сортировку для получения результата. Продолжить чтение "Оконные функции T-SQL и производительность"
До версии SQL Server 2017, если план запроса содержал некорректную оценку кардинального числа (число обрабатываемых строк), ядро базы данных продолжало использовать этот план при каждом выполнении оператора, пока этот план сохранялся в кэше, что часто приводило к падению производительности. Например, план выполнения мог зарезервировать слишком много памяти для одних запросов, в то время как для других недооценить требования к памяти.
Адаптивная обработка запросов призвана решить подобные проблемы посредством более точной оценки кардинального числа при построении планов выполнения запроса. SQL Server 2017 предоставляет эту возможность по умолчанию для баз данных, сконфигурированных с уровнем совместимости 140 или выше.
Продолжить чтение "Адаптивная обработка запроса в SQL Server 2017"
