Друзья, простите за глупый вопрос, но у меня видно воздушный карман в черепной коробке. Подключаюсь к 80 серверу из студии в 90, возможно это важно.
Итак, я всегда думал что план запроса, это есть характеристика его (запроса) производительности, т.е. если два запроса подряд выполнить и план ихний посмотреть, то тот который меньше ресурсов потратил, тот и быстрее. Однако, тут колдую с одним простым запросом (словарь с журналом сцепляю и на экран результат), смотрю планы двух вариантов оного запроса, первый вариант существенно быстрее по плану, смотрю время выполнения — быстрее второй. Я уж и в разных подключениях каждый по отдельности выполнял, и с разными параметрами — ну быстрее второй и всё. Оба запроса в хранимках разных.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Итак, я всегда думал что план запроса, это есть характеристика его (запроса) производительности...
Производительность _сильно_ зависит от кучи вещей — кэша, фрагментации памяти, блокировок, реальных параметров, параллельно выполняющихся запросов, объёма выдаваемых результатов. Так что гадать можно долго, да.
Неоднократно видел тюнинх запросов под пустой кэш. Или оптимизацию запросов по отдельности, без собирания реальной статистики профайлером. В продакшне, разумеется, тормоза
1. На сколько отличаются стоимости планов?
2. Сколько logical/physical reads?
3. Смотрите реальный план, или ожидаемый?
4. В плане нет scan-ов (всё ли покрыто индексами)?
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Друзья, простите за глупый вопрос, но у меня видно воздушный карман в черепной коробке. Подключаюсь к 80 серверу из студии в 90, возможно это важно. ZAM>Итак, я всегда думал что план запроса, это есть характеристика его (запроса) производительности, т.е. если два запроса подряд выполнить и план ихний посмотреть, то тот который меньше ресурсов потратил, тот и быстрее. Однако, тут колдую с одним простым запросом (словарь с журналом сцепляю и на экран результат), смотрю планы двух вариантов оного запроса, первый вариант существенно быстрее по плану, смотрю время выполнения — быстрее второй. Я уж и в разных подключениях каждый по отдельности выполнял, и с разными параметрами — ну быстрее второй и всё. Оба запроса в хранимках разных.
Если вы сравниваете цифры что что студия выводит в строке "query cost (relative to the batch)", то старые версии могли врать в этих цифрах. Насчет новых не уверен, но кто их знает QA этим точно страдал.
Запустите лучше профайлер и посмотрите по ресурсам (cpu, reads, duration) что происходит.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
On 09.12.2010 12:37, ZAMUNDA wrote:
> Итак, я всегда думал что план запроса, это есть характеристика его (запроса) > производительности,
Правильно думал.
т.е. если два запроса подряд выполнить и план ихний > посмотреть, то тот который меньше ресурсов потратил, тот и быстрее.
0) "быстро" и "производительность" не совсем одно и то же.
1) тот, который меньше ресурсов потратил, тот и ПОТРАТИЛ МЕНЬШЕ РЕСУРСОВ.
2) Большинство современных СУБД -- многозадачные системы. MSSQL уж точно такой.
Астрономическое время, прошедшее с момента посылки запроса серверу до момента
получения клиентом ответа ("быстро") зависит ещё и от того, какова общяя
загрузка сервера в данный момент наблюдается. План может быть сколь угодно
хорош, да только выполнять запрос по этому плану может быть просто некому.
Я уж и в > разных подключениях каждый по отдельности выполнял, и с разными параметрами — ну > быстрее второй и всё. Оба запроса в хранимках разных.
Здравствуйте, MasterZiv, Вы писали:
>> Итак, я всегда думал что план запроса, это есть характеристика его (запроса) >> производительности, MZ>Правильно думал.
Спасибо, отлегло!
MZ>1) тот, который меньше ресурсов потратил, тот и ПОТРАТИЛ МЕНЬШЕ РЕСУРСОВ.
ОК! Но мне-то надо чтоб система работала быстрее, и в подавляющем количестве случаев.
MZ>2) Большинство современных СУБД -- многозадачные системы. MSSQL уж точно такой. MZ>Астрономическое время, прошедшее с момента посылки запроса серверу до момента MZ>получения клиентом ответа ("быстро") зависит ещё и от того...
Вот спасибо, а то я сижу перед начальником и никак ему втолковать не могу что "PRINT GETDATE()" тут совершенно не в тему.
MZ>Ты запрос-то покажи ...
Ну как-то так:
SELECT u.ID_User, u.Name, d.CODE_Good, d.Cnt, d.Price
FROM
Users AS u
INNER JOIN
Deals AS d
ON u.ID_User = d.ID_User_Buy
WHERE
u.ID_User = ISNULL(@IDUser, u.ID_User)
AND d.Date BETWEEN @DTBeg AND @DTEnd
А вот если сделать WINTH(INDEX(...)) то ресурсов больше тратится, а работает быстро. Раз в минуту в Deal наливаю записей кучу. И много народу отуда выборку делают пастаянна. Ну я так понимаю теперь, что тут скорее всего самый подходящий индекс пользуют все каму не лень, поэтому он и тормозит; а не самый подходящий никаму не нужен, вот он то и "летает".
PS:Как же я не люблю сопровождать чужие системы <:-F ! Как будто презерватив на голову надевать: тянешь... тянешь... рвётся, сызнова тянешь, а когда наконец натянешь, оказывается что дышать нечем и выглядишь как идиот.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Итак, я всегда думал что план запроса, это есть характеристика его (запроса) производительности, т.е. если два запроса подряд выполнить и план ихний посмотреть, то тот который меньше ресурсов потратил, тот и быстрее. Однако, тут колдую с одним простым запросом (словарь с журналом сцепляю и на экран результат), смотрю планы двух вариантов оного запроса, первый вариант существенно быстрее по плану, смотрю время выполнения — быстрее второй. Я уж и в разных подключениях каждый по отдельности выполнял, и с разными параметрами — ну быстрее второй и всё. Оба запроса в хранимках разных.
была как-то ситуация, что в аналайзере план/запрос работает нормально, а в хранимой процедуре тупит ужасно.
у тебя не такой случай?
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Здравствуйте, MasterZiv, Вы писали:
>>> Итак, я всегда думал что план запроса, это есть характеристика его (запроса) >>> производительности, MZ>>Правильно думал. ZAM>Спасибо, отлегло!
MZ>>1) тот, который меньше ресурсов потратил, тот и ПОТРАТИЛ МЕНЬШЕ РЕСУРСОВ. ZAM>ОК! Но мне-то надо чтоб система работала быстрее, и в подавляющем количестве случаев.
MZ>>2) Большинство современных СУБД -- многозадачные системы. MSSQL уж точно такой. MZ>>Астрономическое время, прошедшее с момента посылки запроса серверу до момента MZ>>получения клиентом ответа ("быстро") зависит ещё и от того... ZAM>Вот спасибо, а то я сижу перед начальником и никак ему втолковать не могу что "PRINT GETDATE()" тут совершенно не в тему.
MZ>>Ты запрос-то покажи ... ZAM>Ну как-то так:
ZAM>SELECT u.ID_User, u.Name, d.CODE_Good, d.Cnt, d.Price
ZAM>FROM
ZAM> Users AS u
ZAM>INNER JOIN
ZAM> Deals AS d
ZAM>ON u.ID_User = d.ID_User_Buy
ZAM>WHERE
ZAM> u.ID_User = ISNULL(@IDUser, u.ID_User)
ZAM> AND d.Date BETWEEN @DTBeg AND @DTEnd
ZAM>
ZAM>А вот если сделать WINTH(INDEX(...)) то ресурсов больше тратится, а работает быстро. Раз в минуту в Deal наливаю записей кучу. И много народу отуда выборку делают пастаянна. Ну я так понимаю теперь, что тут скорее всего самый подходящий индекс пользуют все каму не лень, поэтому он и тормозит; а не самый подходящий никаму не нужен, вот он то и "летает".
у тебя в where есть функция (я про isnull) которая на то, как запрос выполняется. при её наличие бывает что выполняется не индекс сик а, например, скан и тп.
ZAM>PS:Как же я не люблю сопровождать чужие системы <:-F ! Как будто презерватив на голову надевать: тянешь... тянешь... рвётся, сызнова тянешь, а когда наконец натянешь, оказывается что дышать нечем и выглядишь как идиот.
On 09.12.2010 15:36, Spi wrote:
> у тебя в where есть функция (я про isnull) которая на то, как запрос > выполняется. при её наличие бывает что выполняется не индекс сик а, например, > скан и тп.
+1. Лучше всего разбить этот запрос на два,
SELECT u.ID_User, u.Name, d.CODE_Good, d.Cnt, d.Price
FROM
Users AS u
INNER JOIN
Deals AS d
ON u.ID_User = d.ID_User_Buy
WHERE
u.ID_User = @IDUser
AND d.Date BETWEEN @DTBeg AND @DTEnd
и
SELECT u.ID_User, u.Name, d.CODE_Good, d.Cnt, d.Price
FROM
Users AS u
INNER JOIN
Deals AS d
ON u.ID_User = d.ID_User_Buy
WHERE d.Date BETWEEN @DTBeg AND @DTEnd
И звать один из них в зависимости от того, указан ли @IDUser.
Здравствуйте, night beast, Вы писали:
NB>была как-то ситуация, что в аналайзере план/запрос работает нормально, а в хранимой процедуре тупит ужасно. NB>у тебя не такой случай?
Нее... эти грабли уже сломаны. Я делаю новую процу, изменённую (с именем "Проца_" или "Проца_N") и смотрю на работу старой и новой на боевой БД (если это возможно), или на полигоне с максимально боевыми данными. Сначала конечно, тупо запрос выделяю и анализирую, но в конечном итоге сравниваю переделанную процу с изначальной.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
NB>была как-то ситуация, что в аналайзере план/запрос работает нормально, а в хранимой процедуре тупит ужасно. NB>у тебя не такой случай?
А это как раз нормально.
При выполнении конечного запроса в QA известны все условия выборки данных.
А вот при анализе запроса вида select ... where DocumentDate between @dt1 and @dt2 сложно сказать, каков будет период и есть ли смысл в использовании индекса. Поэтому план запроса в QA и ХП могут отличаться.
Здравствуйте, MasterZiv, Вы писали:
>> у тебя в where есть функция (я про isnull) которая на то, как запрос >> выполняется. при её наличие бывает что выполняется не индекс сик а, например, >> скан и тп. MZ>+1. Лучше всего разбить этот запрос на два,
Ишь ты... Хранимко ажна просто полетела в стратосфэру.
Ну я, конечно, знал что это плохо, но чтоб настолько... Сенькью!
Эх жалко CTE нельзя в переменную запихнуть. Да и нет CTE в 80 серваке.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Друзья, простите за глупый вопрос, но у меня видно воздушный карман в черепной коробке. Подключаюсь к 80 серверу из студии в 90, возможно это важно. ZAM>Итак, я всегда думал что план запроса, это есть характеристика его (запроса) производительности, т.е. если два запроса подряд выполнить и план ихний посмотреть, то тот который меньше ресурсов потратил, тот и быстрее. Однако, тут колдую с одним простым запросом (словарь с журналом сцепляю и на экран результат), смотрю планы двух вариантов оного запроса, первый вариант существенно быстрее по плану, смотрю время выполнения — быстрее второй. Я уж и в разных подключениях каждый по отдельности выполнял, и с разными параметрами — ну быстрее второй и всё. Оба запроса в хранимках разных.
1 — вообще-то план запроса сторится в расчете на холодный кэш, если же все или большая часть данных уже в оперативке, план может быть не оптимальным
доказывается просто, сбрасываешь кэш
checkpoint;
dbcc dropcleanbuffers
2 — статы могут быть не пересчитаны, построение плана на ложных предположениях даст паршивый план
3 — гистограмма статов может фэйлить если данные распределены неравномерно и их достаточно много
4 — план строится в предположении что данные в колонках не коррелируют, если это не так — будет фейл
5 — парамеметризованные запросы аля select * from T where C = @C, строятся для "среднего по больнице" @C => очевидно не оптимально
6 — хранимки и другие механизмы кэширования планов, дают относительно оптимальный план, только для первого выполнения
On 09.12.2010 16:26, ZAMUNDA wrote:
> MZ>+1. Лучше всего разбить этот запрос на два, > Ишь ты... Хранимко ажна просто полетела в стратосфэру. > Ну я, конечно, знал что это плохо, но чтоб настолько... Сенькью!
Если хранимка, то можно попробовать ещё и на две хранимки это
разбить. В смысле -- основная хранимка, и из неё вызывать 2
хранимки для реализации каждого запроса.
Правда, я в реалиях современого MSSQL плохо ориентируюсь, может
быть это уже и не актуально.
Идея в том, что хранимка с двумя запросами оптимизируется один
раз под один из запросов, а если каждый запрос в своей хранимке --
у них будут свои планы для каждого запроса, и оптимизатор
будет отрабатывать уже под конкретно этот запрос.
On 09.12.2010 19:16, rm822 wrote:
> 5 — парамеметризованные запросы аля select * from T where C = @C, строятся для > "среднего по больнице" @C => очевидно не оптимально
> ты видимо словил грабли 1,5,6
Здравствуйте, rm822, Вы писали:
Дяденька, я не настоящий сварщик, я просто маску надел... :)
R>2 — статы могут быть не пересчитаны, построение плана на ложных предположениях даст паршивый план
статы это statistics я так понимаю...
R>3 — гистограмма статов может фэйлить если данные распределены неравномерно и их достаточно много
Данных много. А что значит распределены неравномерно? Физически неравномерно? Тут просто мои предшественники вообще про такие понятия как дефрагментация и пересбор индекса не знали ничего, мож в этом дело.
R>4 — план строится в предположении что данные в колонках не коррелируют, если это не так — будет фейл
А что значит "данные в колонках не коррелируют"?
R>5 — парамеметризованные запросы аля select * from T where C = @C, строятся для "среднего по больнице" @C => очевидно не оптимально
Вот тут вообще ничего не понял.
Кстати, что C=@C что C = ISNULL(@C, C) — даёт (в моём случае) index seek, но во втором варианте он дольше работает.
R>6 — хранимки и другие механизмы кэширования планов, дают относительно оптимальный план, только для первого выполнения
Я, когда тестировал, запускал несколько раз и всёравно...
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Здравствуйте, rm822, Вы писали: ZAM>Дяденька, я не настоящий сварщик, я просто маску надел...
R>>2 — статы могут быть не пересчитаны, построение плана на ложных предположениях даст паршивый план ZAM>статы это statistics я так понимаю...
R>>3 — гистограмма статов может фэйлить если данные распределены неравномерно и их достаточно много ZAM>Данных много. А что значит распределены неравномерно? Физически неравномерно? Тут просто мои предшественники вообще про такие понятия как дефрагментация и пересбор индекса не знали ничего, мож в этом дело.
статы дайют ограниченное представление, пусть у тебя статы по колонке X в ячейке статов записано
в диапазоне Х 1-100, 1000 записей, уникальных значений 50, и записей с Х=100 200штук
вопрос, сколько записей вернет select * .... where X=20?
ответ: от 1 до 800, но сиквел считает что в среднем будет 800\49 =~ 16
R>>4 — план строится в предположении что данные в колонках не коррелируют, если это не так — будет фейл ZAM>А что значит "данные в колонках не коррелируют"?
статы по кореллирующим данным бай дефолт не строятся, а если построит вручную — хреново работают
пример
select * from PlasticCards where [действует с] >= 2010 [год рождения владельца] > 2000
если бы данные не корелировали, то если выборка по первому условию дает 5% а по второму 10% от числа записей, то результирующая выбрка дала бы 10% * 5% = 0.5%.
а вот хренушки, детям пластиковые карты не дают,
это и значит коррелируют: сиквел строит план на этих оценках, а они неправильные
R>>5 — парамеметризованные запросы аля select * from T where C = @C, строятся для "среднего по больнице" @C => очевидно не оптимально ZAM>Вот тут вообще ничего не понял. ZAM>Кстати, что C=@C что C = ISNULL(@C, C) — даёт (в моём случае) index seek, но во втором варианте он дольше работает.
под конкретное значение оптимизируется тока where C = <конкретное значение>, а where C = @C — чтобы в среднем для разных @C работало быстро
R>>6 — хранимки и другие механизмы кэширования планов, дают относительно оптимальный план, только для первого выполнения ZAM>Я, когда тестировал, запускал несколько раз и всёравно...
сделай так
dbcc freeproccache
exec mytestproc NULL
exec mytestproc <some value>
QA этим точно страдал.
