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

Откуда:
Сообщений: 104760
Cammomile
Пример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию.

Выберите любую задачу, где важен _порядок_ обработки записей
20 июн 13, 11:57    [14458801]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
aleks2
Guest
CREATE PROCEDURE [dbo].set_default_descriptions @GID INT
AS 

SET NOCOUNT on;


	
	with 
	-- Получаем список характеристик по умолчанию категории - образца
	props as (
				SELECT p.P_ID, p.P_NAME, p.P_UNIT, ggp.GRP_SORT
				FROM TBL_GROUPS_GOODS_PROPS ggp inner join TBL_PROPS p on ggp.GRP_P_ID = p.P_ID
				WHERE ggp.GRP_GR_ID = (SELECT G_GR_ID FROM TBL_GOODS WHERE G_ID = @GID)
	)
	-- ну и все остальное
	merge TBL_GOODS_PROPS tgp
	  using( select *, @GID as GID from props) as p
	  on (tgp.GP_G_ID = p.GID AND tgp.GP_P_ID = p.P_ID)
	  when not matched by target then
	    insert (GP_G_ID, GP_P_ID, GP_UNIT) VALUES (p.GID, p.P_ID, p.P_UNIT)
	  when matched then
        UPDATE  SET GP_UNIT = p.P_UNIT
	  when not matched by source then
	    delete; -- ну, тут надо сообразить
20 июн 13, 12:00    [14458826]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?
20 июн 13, 12:02    [14458835]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу.

Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money
20 июн 13, 12:07    [14458890]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
dimon71
Member

Откуда:
Сообщений: 172
Glory,

Разрешите и мне вставить свои 5 копеек, раз с меня началось.

Действительно. Все зависит от задачи.

Моя задача успешно решилась благодаря просмотру плана исполнения.

Признаю, сглупил, не разобрался, зря потревожил народ.

Оказалось виноват маленький триггерок, который логирует записи. В него затесался забытый запрос об обновлении одной ячейки. И стоимость то всего была 0,51%. Однако на большом количестве - вот и результат.

Просто в голову не пришло посмотреть. Лог и лог. Что там можно исправить.

Теперь мой кривой код на курсоре работает одну секунду. Клиент кнопку нажал - получил результат. Просто отлично.
В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом.

Конечно нужно обязательно прочесть то, что Вы все мне любезно порекомендовали, и это будет обязательно сделано, т.к. много еще всего нужно исправлять. И учиться нужно. Ну пока вот так, на пробах и ошибках.

Спасибо.
20 июн 13, 12:10    [14458919]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Cammomile
ну вот же
DirksDR
dimon71,

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).


Ааа...

Ну использование курсоров на самом деле может очень существенно сказываться на производительности.

Причем, как ни странно, в обе стороны.

На счет наглядности я бы тоже поспорил — запросы читать проще, сразу все ясно, и объективно это проще, декларативная логика запроса описывает, что надо сделать, а не как и что надо сделать, так что можно сказать в двп раза проще понимать.
20 июн 13, 12:24    [14459051]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Cammomile
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?


Они действительно редки в бд.

Но я одну такую знаю — партионое списание товаров по FIFO или LIFO.
20 июн 13, 12:28    [14459082]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
В данном случае наглядность и простота кода лучше.

Извини, наглядностью в твоем коде даже нее пахнет.

Я, не имея специального образования, решил поставленную задачу с хорошим результатом.

Чтобы писать на SQL особенно -то много спец. Образования и не надо,
Надо только знать, что надо писать запросы везде, где только возможно, использовать индексы и выделять серверу память под кэш.
20 июн 13, 12:34    [14459146]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31445
dimon71
В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом.
Конечно, нагладность и простота очень важны, и то, что задача решена - замечательно, но конкретно решение вашей задачи нагляднее и проще читается без курсоров.

Нужно комментарии на русском в процедуре записать на языке SQL в одном запросе, только и всего.
Просто для вас SQL не основной язык, вы к нему не привыкли, не чувствуете его.
20 июн 13, 12:37    [14459188]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3618
MasterZiv
Cammomile
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?


Они действительно редки в бд.

Но я одну такую знаю — партионое списание товаров по FIFO или LIFO.

это частный случай нарастающего итога - той самой класической и одной единственной задачи (хотя и весьма распространенной) где курсор лучше.

Умрет с появлением инструкции:
update ....
from ...
order by ...
20 июн 13, 12:40    [14459215]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Glory
Cammomile
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу.

Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money

1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.
2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.
20 июн 13, 12:41    [14459231]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.

Он был еще в 2000. Только он не гарантирует порядок.
А именно про задачи завязанные на порядок обработки записей я и говорил.

Cammomile
1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.

Вы уже проверили это ?
20 июн 13, 12:43    [14459253]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Я спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.

"Только он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.
20 июн 13, 13:07    [14459455]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
Я спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.

Ага. Слышал в вашего Карузо. Мне Рабинович напел

Cammomile
Только он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.

курсор не единственный способ получения такого нарастающего итога.
20 июн 13, 13:10    [14459476]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Ну там весьма авторитетный рабинович напел.

Так, вы сказали что есть случаи когда курсор быстрее аналогичного апдейта/селекта/ инсерта.
В вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?
20 июн 13, 13:23    [14459568]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
В вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?

Что значит НЕаналогичный ? update from join он и африке update
Или вы знаете другие команды обновления ?
20 июн 13, 13:25    [14459579]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
update t set f = 1 where d in (1,2,3)


аналогичный курсор который никак не может быть быстрее (типа того что делает автор топика)

declare @d int 
declare cur cursor for select d from t where d in (1,2,3) 
fetch next from cur into @d
while @@fetch_status = 0 begin  
  update t set f=1 where d= @d 
  fetch next from cur into @d 
end
20 июн 13, 13:37    [14459722]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
аналогичный курсор который никак не может быть быстрее (типа того что делает автор топик

Смешной вы. Вы под аналогией понимаете давайте выполнять массовый апдейт в цикле по одной записи ?
Вы заявили, что все курсоры обязательно должны быть переписаны в запросы.
Даже у автора темы идут какие-то рассчеты и проверки. И вы даже не знаете, можно ли их осуществить в вашем update t set f = 1 where d in (1,2,3)
20 июн 13, 13:43    [14459788]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
17-77
Member

Откуда:
Сообщений: 1438
dimon71,

можно оптимизировать, надо избавиться от курсора
20 июн 13, 14:26    [14460165]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
invm
Member

Откуда: Москва
Сообщений: 9413
Cammomile,

Best approaches for running totals
20 июн 13, 14:26    [14460166]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
О годная аналитика. Сейчас почитаем.

Кстати, касаемо "стремного апдейта"

Мне кажется, что "не гарантирует порядка" больше спекуляция
1 - нет документированных случаев когда этот метод подвел бы
2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали
3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты

По мне так вполне надежно, не ?
20 июн 13, 14:32    [14460210]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
Мне кажется, что "не гарантирует порядка" больше спекуляция
1 - нет документированных случаев когда этот метод подвел бы

У вас есть документированный способ указания порядка обработки записей ?

Cammomile
2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали

Это вы цитируете документацию ?

Cammomile
3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты

Разговор не про саму конструкцию, про гарантированный порядок.
20 июн 13, 14:56    [14460418]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Shakill
Member

Откуда: мск
Сообщений: 1880
Cammomile
О годная аналитика. Сейчас почитаем.

Кстати, касаемо "стремного апдейта"

Мне кажется, что "не гарантирует порядка" больше спекуляция
1 - нет документированных случаев когда этот метод подвел бы
2 - сама конструкция подразумевает, что ее надо использовать именно для нарастающего итога, а эскуль сервер все-таки не идеоты писали
3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты

По мне так вполне надежно, не ?
такая логика для ответственных применений не годится. разработчики сервера вам ничего по поводу этой конструкции не обещают => слово "надежно" тут вообще не применимо. о чем и говорится в статье, кстати
I’ll re-state that I don’t believe this approach is safe for production, regardless of the testimony you’ll hear from people indicating that it “never fails.” Unless behavior is documented and guaranteed, I try to stay away from assumptions based on observed behavior. You never know when some change to the optimizer’s decision path (based on a statistics change, data change, service pack, trace flag, query hint, what have you) will drastically alter the plan and potentially lead to a different order
20 июн 13, 15:05    [14460500]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
invm
Member

Откуда: Москва
Сообщений: 9413
Cammomile
Мне кажется, что "не гарантирует порядка" больше спекуляция

Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 1
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 2
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть 3
20 июн 13, 15:37    [14460725]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Раз пошла такая пьянка- режь последний огурец !
20 июн 13, 15:38    [14460732]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить