drop table if exists dbo.t1, dbo.t2; drop view if exists dbo.v_tables; create table dbo.t1 (a int, b int, c int); insert into dbo.t1 values (1, 1, 1); create table dbo.t2 (a int, b int, c int); insert into dbo.t2 values (2, 2, 2); go create view dbo.v_tables as select 't1' as table_name, a, b, c from dbo.t1 union all select 't2' as table_name, a, b, c from dbo.t2 go select a, b, c from dbo.v_tables where table_name = 't1'; select a, b, c from dbo.v_tables where table_name = 't2';
это жопа ж будет с производительностью
И почему же?
у меня есть предположение, что если добавится and a<4 то там всё станет грустно
Ну добавьте и посмотрите план
ща доползу до компа
такие дела. пока там константа - всё хорошо, когда там параметр, то всё плохо
Когда параметр, то тоже хорошо. См. фильтры - это startup expression predicate. Погуглите что это
Саша, на картинке сканируются две таблички. Потом объединяются. Только потом работает фильтр. Что вы хотите спросить у гугла ?
План выполняется слева направо
Параметр снифинг?
It depends Читайте статью. https://www.sqlpassion.at/archive/2015/08/24/how-to-read-an-execution-plan/#:~:text=Therefore%20the%20resulting%20data%20flow,flow%20within%20the%20execution%20plan.
Optimized for unknown может помочь, особенно когда нет нормального распределения.
План выполняется слева направо, данные возвращаются справа налево Процесс выполнения плана можно рассматривать как раскручивание рекурсии. optimize for unknown в данном случае вообще не при делах
Чтение плана слева направо требует очень хорошего понимания физической работы операторов и методов которые они используют. Если вы конечно один из разработчиков SQL engine с опытом 10+, то для вас не составит труда раскрутить план с 30-40 операторами. Такой способ чтения, по моему мнению, применяется очень редко. Другой подход, он кстати мне ближе, это логическое выполнение плана. В данном подходе вы не задумываетесь о физической стороне вопроса, какой метод и как вызывает нижестоящий метод по плану, а читаете поток данных. Он более прост для восприятия и быстрого анализа. Теперь про optimize for unknown. На каком основании вы определили, что это не подходит?
План можно читать в любом направлении, хоть снизу вверх или сверху вниз. Но без понимания как план выполняется и возникают казусы как с @blackskif И для достижения такого понимания достаточно всего лишь изучить статью документации, в которой описан принцип работы любого итератора. Знать при этом как работают сами итераторы вовсе не обязательно. Касаемо Optimized for unknown - если найдете в обсуждаемом запросе место, где переменная влияет на оценку строк, то да, может помочь. Кстати, даже если бы было место где переменная влияет на оценку, Optimized for unknown все равно бесполезен, ибо нет снифинга параметров.
Если вы об этой статье https://docs.microsoft.com/ru-ru/sql/relational-databases/showplan-logical-and-physical-operators-reference?view=sql-server-ver15 То прочитав ее вы получите знания по тому какой из операторов что делает, но ни как что-то подправить или улучшить. Про хинт, прочитайте коммент под планом.
Еще раз - что бы понимать в каком порядке выполняются итераторы в плане, не нужно знать о том как выполняется конкретный итератор. Про хинт. Обсуждаемый запрос. use tempdb; go drop table if exists dbo.t1, dbo.t2; drop view if exists dbo.v_tables; create table dbo.t1 (a int, b int, c int); insert into dbo.t1 values (1, 1, 1); create table dbo.t2 (a int, b int, c int); insert into dbo.t2 values (2, 2, 2); go create view dbo.v_tables as select 't1' as table_name, a, b, c from dbo.t1 union all select 't2' as table_name, a, b, c from dbo.t2 go set statistics xml, io on; declare @tn varchar(100) = 't1' select a, b, c from dbo.v_tables where table_name = @tn; set statistics xml, io off; Рекомендую посмотреть на сам план, а не на его изображение. А потом объяснить как на него повлияет optimize for unknown Так же очень сильно рекомендую посмотреть на результат statistics io - на предмет того, из каких же таблиц читались данные.
Обсуждают сегодня