Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 outer apply  [new]
оптимизатор1
Guest
Добрый вечер!

Все запросы с outer apply стоят очень дорого!

Причина в этом операторе?
16 сен 13, 18:50    [14846611]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Причина в том, что этот оператор нужно уметь применять.
16 сен 13, 19:07    [14846676]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 393
Помогите оптимизировать запрос!
Тормозит вызов inline-функции dbo.f_PriceOutNats
Подскажите как правильно переписать с помощью APPLY?

select
	pt.WareId,
	pt.Price,
	wd.DiscCrossId,
	CASE 
	  when GPP.GrossProfitProcentId is null
	  then CASE
		     when wd.DiscProc > 0
		     then PT.Price / 100.0 * (100.0 - wd.DiscProc)
		     else wd.DiscPrice * RD.RateCur
		   END 
	  else CASE -- для группы НАЦЕНКА
			 when dg.DiscGroupTypeId = 3
			 then dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 2) -- тип группы наценки - Индивидуальная
			 else dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 1) -- тип группы наценки - Стандартная
		   END
	END as PriceOut, 
	dg.DiscGroupName
from (select WareId from tWareQnt where tQntWare > 0) QW
join tPriceToday pt on pt.WareId = QW.WareId
join tWareDisc wd on wd.WareId = pt.WareId
					and @Today BETWEEN wd.DateBegin AND wd.DateEnd
join tDiscCross dc ON dc.DiscCrossId = wd.DiscCrossId
join @RD RD on RD.Cur1 = wd.Currency_ID
join sDiscGroup dg ON dg.DiscGroupId = dc.DiscGroupId
					and dg.DiscGroupTypeId <> 2 -- не акция
				    and exists (select 1 from tDiscCross DC join tKagDisc KD on KD.DiscCrossId = DC.DiscCrossId where DC.DiscGroupId = dg.DiscGroupId)
left join tGrossProfitProcent GPP on GPP.DiscCrossId = wd.DiscCrossId
left join tWareGroup wg on wg.WareId = pt.WareId
						and wg.GroupTypeId = @NoCheckGrType
where wg.WareId is null   -- товар не входит в группу "без контроля БМ"
6 июн 14, 17:05    [16134156]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
OUTER APPLY как и любой join опирается на индексы. Утверждение OUTER APPLY оператор тяжёлый неверно.

У меня была одна задача месяц назад надо было подтянуть для каждой строки первой таблицы одну строку из нескольких из другой таблицы и я попробовал три варианта GROUP BY, OUTER APPLY и ROW_NUMBER

OUTER APPLY показал лучший результат
6 июн 14, 17:22    [16134270]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Valerii79
Помогите оптимизировать запрос!
Тормозит вызов inline-функции dbo.f_PriceOutNats
Подскажите как правильно переписать с помощью APPLY?

select
	pt.WareId,
	pt.Price,
	wd.DiscCrossId,
	CASE 
	  when GPP.GrossProfitProcentId is null
	  then CASE
		     when wd.DiscProc > 0
		     then PT.Price / 100.0 * (100.0 - wd.DiscProc)
		     else wd.DiscPrice * RD.RateCur
		   END 
	  else CASE -- для группы НАЦЕНКА
			 when dg.DiscGroupTypeId = 3
			 then dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 2) -- тип группы наценки - Индивидуальная
			 else dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 1) -- тип группы наценки - Стандартная
		   END
	END as PriceOut, 
	dg.DiscGroupName
from (select WareId from tWareQnt where tQntWare > 0) QW
join tPriceToday pt on pt.WareId = QW.WareId
join tWareDisc wd on wd.WareId = pt.WareId
					and @Today BETWEEN wd.DateBegin AND wd.DateEnd
join tDiscCross dc ON dc.DiscCrossId = wd.DiscCrossId
join @RD RD on RD.Cur1 = wd.Currency_ID
join sDiscGroup dg ON dg.DiscGroupId = dc.DiscGroupId
					and dg.DiscGroupTypeId <> 2 -- не акция
				    and exists (select 1 from tDiscCross DC join tKagDisc KD on KD.DiscCrossId = DC.DiscCrossId where DC.DiscGroupId = dg.DiscGroupId)
left join tGrossProfitProcent GPP on GPP.DiscCrossId = wd.DiscCrossId
left join tWareGroup wg on wg.WareId = pt.WareId
						and wg.GroupTypeId = @NoCheckGrType
where wg.WareId is null   -- товар не входит в группу "без контроля БМ"


А что в этой функции -- мегаподзапрос?
6 июн 14, 17:24    [16134282]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Glory
Member

Откуда:
Сообщений: 104760
Valerii79
Тормозит вызов inline-функции dbo.f_PriceOutNats

У вас скалярная функция
6 июн 14, 17:27    [16134298]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 393
Glory
Valerii79
Тормозит вызов inline-функции dbo.f_PriceOutNats

У вас скалярная функция

Да!

CREATE  FUNCTION [dbo].[f_PriceOutNats] (@WareId int, @DiscCrossId int, @TypeRate int)  
RETURNS float AS  

-- ====================================================================== --
BEGIN 
-- ====================================================================== --

DECLARE @RegCur char(3)
SET @RegCur = dbo.f_GetRegCur()

  RETURN
 
(
select isnull(dbo.f_SixPack((t.PriceRegIn*t.InputKoef/(1-(t.GrossProfitProcentValue/100)))),0) 

as PriceOutNats 
         
from (
select top 1 K.KagId, K.KagName, isnull(IK.InputKoef,1) as InputKoef, 
GP.GrossProfitProcentValue, PP.PricePurch, 
(PP.PricePurch*dbo.f_Rate(PP.PricePurchCur, @RegCur , GETDATE(), @TypeRate)) as PriceRegIn,
 PP.cPricePurchUSD, PP.PricePurchDate
from tGrossProfitProcent GP 
inner join sKag K on K.KagId = GP.SupplierId
left join tDiscInputKoef IK on IK.KagId = GP.SupplierId
inner join tPricePurch PP on PP.SupplierId = GP.SupplierId and PP.WareId = @WareId
where GP.DiscCrossId = @DiscCrossId 
order by PP.PricePurchDate desc) t 
)
-- ====================================================================== --
END
-- ====================================================================== --
6 июн 14, 17:46    [16134428]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
iap
Member

Откуда: Москва
Сообщений: 46999
Valerii79
Glory
пропущено...

У вас скалярная функция

Да!
А зачем Вы нам голову морочите?
По-Вашему, это всё равно?
Для скалярной функции APPLY не нужен.
И запрос практически не лечится, если не ошибаюсь.
6 июн 14, 18:09    [16134543]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 393
iap
Valerii79
пропущено...

Да!
А зачем Вы нам голову морочите?
По-Вашему, это всё равно?
Для скалярной функции APPLY не нужен.
И запрос практически не лечится, если не ошибаюсь.

Ошибаетесь!
Сделаю без APPLY!
6 июн 14, 18:11    [16134555]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31429
iap
И запрос практически не лечится, если не ошибаюсь.
В принципе можно сделать инлайн функцию.

Но ещё лучше, конечно, раскрыть.

Подход у Valerii79 конечно ужасен, всё на функциях.
6 июн 14, 19:07    [16134754]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
OUTER APPLY как и любой join опирается на индексы.
Не совсем верно. Hash join-у на индексы фиолетово.
6 июн 14, 19:59    [16135007]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Valerii79
Member

Откуда: Кишинев, Молдавия
Сообщений: 393
alexeyvg
Подход у Valerii79 конечно ужасен, ...


Окститесь, господин критик!
Прежде чем критиковать, спросите чей это код.
7 июн 14, 13:24    [16136614]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Valerii79
Прежде чем критиковать, спросите чей это код.
А про код и не говорили, говорили про подход "оптимизации".

Старайтесь никогда не пользоваться скалярками.
Оптимизировать сверху вниз, т.е. глобально/целостно посмотреть на систему и найти базовые затыки.
Valerii79
Подскажите как правильно переписать с помощью APPLY?
Что конкретно?

Вам надо научится самому понимать что да как фунчиклирует. Научитесь читать планы, далее экспериментируйте, переписывайте запросы и наблюдайте что происходит.

Понимание тупой базовой идеи декларативного подхода очень желательно.
Можно поговорить о принципах описания запросов.

Valerii79
Подскажите как правильно переписать с помощью APPLY?
Это вопрос эквивалентный такому:
Как рассказать о воспитании используя только буквы {т,ь,б,я,л}?
Язык должен быть целостным и самодостаточным, у него нет ничего на манер "золотой пули", моды или чего-то эдакого.

автор
select
	pt.WareId,
	pt.Price,
	wd.DiscCrossId,
	CASE 
	  when GPP.GrossProfitProcentId is null
	  then CASE
		     when wd.DiscProc > 0
		     then PT.Price / 100.0 * (100.0 - wd.DiscProc)
		     else wd.DiscPrice * RD.RateCur
		   END 
	 else CASE -- для группы НАЦЕНКА
			 when dg.DiscGroupTypeId = 3
			 then dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 2) -- тип группы наценки - Индивидуальная
			 else dbo.f_PriceOutNats (pt.WareId, wd.DiscCrossId, 1) -- тип группы наценки - Стандартная
		   END
	END as PriceOut, 
	dg.DiscGroupName
from (select WareId from tWareQnt where tQntWare > 0) QW
join tPriceToday pt on pt.WareId = QW.WareId
join tWareDisc wd on wd.WareId = pt.WareId
					and @Today BETWEEN wd.DateBegin AND wd.DateEnd
join tDiscCross dc ON dc.DiscCrossId = wd.DiscCrossId
join @RD RD on RD.Cur1 = wd.Currency_ID
join sDiscGroup dg ON dg.DiscGroupId = dc.DiscGroupId
					and dg.DiscGroupTypeId <> 2 -- не акция
				    and exists (select 1 from tDiscCross DC join tKagDisc KD on KD.DiscCrossId = DC.DiscCrossId where DC.DiscGroupId = dg.DiscGroupId)
left join tGrossProfitProcent GPP on GPP.DiscCrossId = wd.DiscCrossId
left join tWareGroup wg on wg.WareId = pt.WareId
						and wg.GroupTypeId = @NoCheckGrType
where wg.WareId is null   -- товар не входит в группу "без контроля БМ"
Не надо путать связки (ON) и условия отбора (WHERE) это пр смыслу разные вещи, и по описанию пишутся по разному.
Не надо писать Exists через LEFT JOIN, это непонятно и не каждый скуль поймёт правильно (да, мне тоже не нравится стиль Exists, но селяви)
И имя схемы у таблиц и других объектов пишите всегда (опять же по нескольким причинам).
И форматируйте код более аккуратно.
7 июн 14, 14:38    [16136754]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
автор
CREATE  FUNCTION [dbo].[f_PriceOutNats] (@WareId int, @DiscCrossId int, @TypeRate int)  
RETURNS float AS BEGIN
-- ====================================================================== --
DECLARE @RegCur char(3)
SET @RegCur = dbo.f_GetRegCur()
RETURN (

select isnull(dbo.f_SixPack((t.PriceRegIn*t.InputKoef/(1-(t.GrossProfitProcentValue/100)))),0)  as PriceOutNats 
from (
	select top 1 K.KagId, K.KagName, isnull(IK.InputKoef,1) as InputKoef, 
		GP.GrossProfitProcentValue, PP.PricePurch, 
		(PP.PricePurch*dbo.f_Rate(PP.PricePurchCur, @RegCur , GETDATE(), @TypeRate)) as PriceRegIn,
		PP.cPricePurchUSD, PP.PricePurchDate
	from tGrossProfitProcent GP 
inner join sKag K on K.KagId = GP.SupplierId
left join tDiscInputKoef IK on IK.KagId = GP.SupplierId
inner join tPricePurch PP on PP.SupplierId = GP.SupplierId and PP.WareId = @WareId
	where GP.DiscCrossId = @DiscCrossId 
	order by PP.PricePurchDate desc) t 
)
-- ====================================================================== --
END
Float и финансы несовместимы. Забудьте про этот неточный тип данных. Money (почти везде) и нужный Decimal. Притом нужно не забить болт на вычисления, а как учили в школе или на первом курсе, согласно диапазонам точности и допустимости.
Скалярки фтопку.
Глобальные переменные (dbo.f_GetRegCur) фтопку.
Настройки лучше через константную VIEW подключать, в базовом запросе.

В параметризованных представлениях (inline functions) пишите все возможные в системе вычисления по указанному в названии смыслу(ам). К примеру в dbo.fnPrice(...) будут все виды, и In и Out и "Индивидуальная" и "Стандартная", просто как колонки, с нормальными именами, а не непонятные коды (2,1) через @TypeRate.

И лучше не заворачивать вычисления конкретных значений с настроечной системой (тем более в скалярках). Это получается для каждого значения (коих может быть несколько для каждой строки) будет каждый раз подыматься система настроек, которая единая/одинаковая для всего запроса (или большой части строк) - это же очевидная неэффективность.
Вычисления пусть будут простыми законченными выражениями, никак не связанные с системой (желательно никаких FROM).
Unix way это общий декларативный принцип, он не привязан к языку, к Си там или Питон.
7 июн 14, 15:11    [16136805]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
a_voronin
как и любой join опирается на индексы
Ага, счас, особенно Hash соединение.
8 июн 14, 20:18    [16139211]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Mnior
a_voronin
как и любой join опирается на индексы
Ага, счас, особенно Hash соединение.


Ребят, не надо мне лапшу на уши вешать. В течение последнего месяца outer apply этих наоптимизировал много. То, что у вас возникает Hash и индекс ему не помогает, это означает лишь одно, что индекс вы выбрали неправильный. Я срезал запросы с 5 часов до нескольких минут и делал такие вещи десятки раз.

Вообще я уже давно не обращаю внимание на тип JOIN. Иногда план не дает правильной картины, нужно чутьё.
9 июн 14, 16:36    [16143900]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
a_voronin
Mnior
пропущено...
Ага, счас, особенно Hash соединение.


Ребят, не надо мне лапшу на уши вешать. В течение последнего месяца outer apply этих наоптимизировал много. То, что у вас возникает Hash и индекс ему не помогает, это означает лишь одно, что индекс вы выбрали неправильный. Я срезал запросы с 5 часов до нескольких минут и делал такие вещи десятки раз.

Вообще я уже давно не обращаю внимание на тип JOIN. Иногда план не дает правильной картины, нужно чутьё.


жэсть! лайкнул
9 июн 14, 17:13    [16144254]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
a_voronin
Ребят, не надо мне лапшу на уши вешать.
А не надо пространные выражения писать. Всё намного сложнее.
a_voronin
это означает лишь одно, что индекс вы выбрали неправильный.
С чего вы решили? Вы хотите сказать что ВСЕ запросы идут чисто по индексам? (это либо "масло маслянное" или не так, в зависимости от смысла)
Существует компромисс, что некоторые запросы идут по hash. Ибо он работает намного быстрее (в определённом окружении), чем к примеру LOOP Seek, который, естественно требует индекс (Seek).
А свести упорядоченность данных до MERGE JOIN - это вообще не так часто получается.

Так что не надо ля-ля, про месяцы оптимизаций.
a_voronin
Я срезал запросы с 5 часов до нескольких минут и делал такие вещи десятки раз.
Опять 25. Это когда стали частности определять общности? Вы по существу говорите, а не кичитесь, ибо не перед кем.
a_voronin
Вообще я уже давно не обращаю внимание на тип JOIN. Иногда план не дает правильной картины, нужно чутьё.
Это вообще что-то невнятное. А главное бессмысленное.
План даёт практически всегда всю картину где накосячил в архитектуре.
А "чутьё" - это непонимание ни процессов, ни принципов. Если вы не хотите уметь формализовывать, то смысл тусоваться на форуме?

PS: И прошу, не надо нервничать, я придираюсь к написанному, что может и не имелось ввиду или было невнятно формализовано.
9 июн 14, 20:34    [16145094]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Ребят, не надо мне лапшу на уши вешать. В течение последнего месяца outer apply этих наоптимизировал много. То, что у вас возникает Hash и индекс ему не помогает, это означает лишь одно, что индекс вы выбрали неправильный.
Если вам не встречались случаи где hash join быстрее поиска по индексу, то не надо считать, что вы умнее других.

a_voronin
Иногда план не дает правильной картины, нужно чутьё.
а про чутьё - очень смешно Доктора хауса пересмотрели наверное? Так в SQL-е все намного проще. Сервер написали люди и запросы он выполняет в точности по плану. Если вы не умеете интерпретировать планы, то учитесь, а не показывайте всем свой непрофессионализм.
9 июн 14, 20:52    [16145157]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Mind
a_voronin
Ребят, не надо мне лапшу на уши вешать. В течение последнего месяца outer apply этих наоптимизировал много. То, что у вас возникает Hash и индекс ему не помогает, это означает лишь одно, что индекс вы выбрали неправильный.
Если вам не встречались случаи где hash join быстрее поиска по индексу, то не надо считать, что вы умнее других.

a_voronin
Иногда план не дает правильной картины, нужно чутьё.
а про чутьё - очень смешно Доктора хауса пересмотрели наверное? Так в SQL-е все намного проще. Сервер написали люди и запросы он выполняет в точности по плану. Если вы не умеете интерпретировать планы, то учитесь, а не показывайте всем свой непрофессионализм.


Уважаемый, проблема не в том, что я не умею читать планы, а в том, что я начитался и насмотрелся их куда больше вашего. Я насмотрелся их на SQL Server и на Oracle и сделал ни одно хранилище данных и оптимизировал ни одну проблемную ситуацию на высоконагруженных серверах. Когда никто в нашей компании не мог оптимизировать запрос, звали меня.

Если вы говорить, что можно обойтись без чутья, то вы -- непрофессионал, а не я. Вы видели когда-нибудь, как план меняться от параметров? Вы видели, когда-нибудь как план меняется при непонятных обстоятельствах? Вы дели запросы, которые из окна исполняются быстро, на продакшн сервере виснут на часы? У вас много было систем с 100+ запросами в секунду?
9 июн 14, 21:06    [16145194]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37050
Модератор: a_voronin, давайте без писькомерства и подстрекательства к оному. В приличном обществе такое не одобряется.
З.Ы. И, да: "ни одно хранилище данных" = 0 хранилищ данных.


Сообщение было отредактировано: 10 июн 14, 04:14
9 июн 14, 21:10    [16145200]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37050
a_voronin
Уважаемый, проблема не в том, что я не умею читать планы, а в том, что я начитался и насмотрелся их куда больше вашего. Я насмотрелся их на SQL Server и на Oracle и сделал ни одно хранилище данных и оптимизировал ни одну проблемную ситуацию на высоконагруженных серверах. Когда никто в нашей компании не мог оптимизировать запрос, звали меня.

Если вы говорить, что можно обойтись без чутья, то вы -- непрофессионал, а не я. Вы видели когда-нибудь, как план меняться от параметров? Вы видели, когда-нибудь как план меняется при непонятных обстоятельствах? Вы дели запросы, которые из окна исполняются быстро, на продакшн сервере виснут на часы? У вас много было систем с 100+ запросами в секунду?
Из вашего пассажа я могу сделать лишь вывод, что у вас лучше всех в вашей компании работает палец, которым вы тыкаете в небо: чаще попадаете, куда надо.

В этом способе (и способности) ничего криминального я не вижу, но выглядит очень странно, что вы обвиняете в непрофессионалами тех, кто пользуется более логичными способами.
9 июн 14, 21:18    [16145216]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4804
Гавриленко Сергей Алексеевич
a_voronin
Уважаемый, проблема не в том, что я не умею читать планы, а в том, что я начитался и насмотрелся их куда больше вашего. Я насмотрелся их на SQL Server и на Oracle и сделал ни одно хранилище данных и оптимизировал ни одну проблемную ситуацию на высоконагруженных серверах. Когда никто в нашей компании не мог оптимизировать запрос, звали меня.

Если вы говорить, что можно обойтись без чутья, то вы -- непрофессионал, а не я. Вы видели когда-нибудь, как план меняться от параметров? Вы видели, когда-нибудь как план меняется при непонятных обстоятельствах? Вы дели запросы, которые из окна исполняются быстро, на продакшн сервере виснут на часы? У вас много было систем с 100+ запросами в секунду?
Из вашего пассажа я могу сделать лишь вывод, что у вас лучше всех в вашей компании работает палец, которым вы тыкаете в небо: чаще попадаете, куда надо.

В этом способе (и способности) ничего криминального я не вижу, но выглядит очень странно, что вы обвиняете в непрофессионалами тех, кто пользуется более логичными способами.


Просто я часто принимаю нестандартные решение. Например, вместо индекса сделать вторую упрощённую таблицу или перенести задачу на уровень бизнес логики. Возможно вы не поняли, но я пересмотрел очень много планов и я знаю, что такое NESTED LOOP MERGE и HASH JOIN. Понятно, что HASH JOIN может оказаться лучше индекса. Непонятно, почему оппонент решил, что я что-то имею против. Но я повидал слишком много "магии", когда что-то не работает согласно документации (магии в коде, которые писал как правило не я), чтобы согласиться с тем, что все всегда логично.
10 июн 14, 11:46    [16147710]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
a_voronin
Но я повидал слишком много "магии", магии в коде, которые писал как правило не я
Это всё замечательно, только не надо это валить на всех и всё.

Мне кажется вы ещё не очень понимаете что тут происходит. Кто есть кто тут, и для чего и как.
a_voronin
Например, вместо индекса сделать вторую упрощённую таблицу
Ну и смысл? Только геморроя больше.
Не надо о такой хрени писать в общественных местах.
Даже о том, что создавать нормальную форму путём разрезания таблы на несколько, со связками 1н к 1му.
10 июн 14, 15:35    [16149635]     Ответить | Цитировать Сообщить модератору
 Re: outer apply  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
a_voronin
Уважаемый, проблема не в том, что я не умею читать планы, а в том, что я начитался и насмотрелся их куда больше вашего.
Давайте каждый будет сам считать сколько и каких запросов он в своей жизни видел?
a_voronin
Когда никто в нашей компании не мог оптимизировать запрос, звали меня.
У остальных наверное нет чутья

a_voronin
Если вы говорить, что можно обойтись без чутья, то вы -- непрофессионал, а не я.
Еще раз, оптимизация запросов это не прогноз погоды. Да, там много переменных, которые сложно все учесть, но там нет магии. В одних и тех же условиях, один и тот же запрос всегда будет выполнятся одинаково.

a_voronin
Вы видели когда-нибудь, как план меняться от параметров? Вы видели, когда-нибудь как план меняется при непонятных обстоятельствах? Вы дели запросы, которые из окна исполняются быстро, на продакшн сервере виснут на часы?
Э-э-э. Как бы да, видел. Обычно это происходит из-за parameter sniffing и/или из-за различной/изменяющейся статистики. И никаких особых догадок там не нужно. Смотрим значения параметров с которыми скомпилировался запрос, смотрим статистики, анализируем, фиксаем, делаем выводы.
Еще можно напороться на какой нибудь баг оптимизатора. Тогда ищем в гугле или на connect'е и если это действительно никому доселе неизведанная проблема, то заводим тикет. Не факт правда что его вообще пофиксают, но все же.
a_voronin
У вас много было систем с 100+ запросами в секунду?
Нет, потому что я редко работаю с OLTP. У меня скорее наоборот 1 запрос в 100 секунд.
11 июн 14, 03:33    [16152111]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить