powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Можно ли существенно оптимизировать данную процедуру.
57 сообщений из 57, показаны все 3 страниц
Можно ли существенно оптимизировать данную процедуру.
    #38303999
dimon71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Доброго вечера, уважаемые!

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

Мною написано много подобных процедур, стиль написания будет понятен из листинга ниже.
Можно ли существенно ускорить их выполнение? К примеру данный запрос выполняется секунд 20. Запросы идут потоком и в итоге все это долго.
Если найдется спец который существенно ускорит данное безобразие - я готов заплатить.
Может укажете на какие кардинальные ошибки?

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
-- Переносит характеристики товара по умолчанию на товар
USE iNETsHOP_scompt
GO

DROP PROCEDURE [dbo].set_default_descriptions
GO

CREATE PROCEDURE [dbo].set_default_descriptions @GID INT
AS 

SET NOCOUNT on;

DECLARE @GRID INT,
	@PID INT,
	@ETALON_CATEGORY VARCHAR (50),
	@PROP_ETALON_NAME VARCHAR (50),
	@PROP_ETALON_SORT INT,
	@PROP_ETALON_ID INT,
	@PROP_UNIT VARCHAR (20),
	@GP_ID	INT;

	-- Узнаем к какой категории относится товар
	SELECT @GRID = G_GR_ID FROM TBL_GOODS WHERE G_ID = @GID;

	-- Получаем список характеристик по умолчанию категории - образца
	DECLARE cursor_default_props CURSOR LOCAL FOR
	SELECT p.P_ID, p.P_NAME, p.P_UNIT, ggp.GRP_SORT
	FROM TBL_GROUPS_GOODS_PROPS ggp, TBL_PROPS p
	WHERE ggp.GRP_P_ID = p.P_ID AND ggp.GRP_GR_ID = @GRID
	ORDER BY ggp.GRP_SORT;
	
	OPEN cursor_default_props;

	FETCH NEXT FROM cursor_default_props INTO @PROP_ETALON_ID, @PROP_ETALON_NAME, @PROP_UNIT, @PROP_ETALON_SORT;
	WHILE (@@FETCH_STATUS <> -1)
		BEGIN

	-- Получаем данные, есть ли для данного товара характеристика по умолчанию, такая же
	-- как и эталонная характеристика
	-- Если характеристика есть, то запрос вернет 1 или другое число, если есть дублирующиеся характеристики
	-- Если нет - вернется 0

		SET	@GP_ID = NULL;

		SELECT	@GP_ID = GP_ID
		FROM TBL_GOODS_PROPS
		WHERE GP_G_ID = @GID AND GP_P_ID = @PROP_ETALON_ID;

--PRINT CAST (@PROP_ETALON_ID AS VARCHAR (10))+ ' ' + @PROP_ETALON_NAME + ' ' + CAST(@PROP_ETALON_SORT AS VARCHAR (10));

		IF @GP_ID IS NULL
			BEGIN
--PRINT 'Характеристики по умолчанию такой нет. Добавляем.';
			INSERT INTO TBL_GOODS_PROPS (GP_G_ID, GP_P_ID, GP_UNIT) VALUES (@GID, @PROP_ETALON_ID, @PROP_UNIT);
			END 
--PRINT ' ';
		ELSE
			-- характеристика есть у товара, обновляем сортировку и еденицы измерения
			BEGIN
			UPDATE TBL_GOODS_PROPS SET GP_UNIT = @PROP_UNIT WHERE GP_ID = @GP_ID;
			END
		

		FETCH NEXT FROM cursor_default_props INTO @PROP_ETALON_ID, @PROP_ETALON_NAME, @PROP_UNIT, @PROP_ETALON_SORT;
		END
	CLOSE cursor_default_props;
	DEALLOCATE cursor_default_props;

	-- Удаляем характеристики привязанные к товару, но не указанные в умолчании.

	DELETE FROM TBL_GOODS_PROPS WHERE GP_G_ID = @GID AND GP_P_ID IN
	(SELECT P_ID FROM TBL_PROPS, TBL_GOODS_PROPS
	WHERE P_ID = GP_P_ID AND GP_G_ID = @GID AND P_ID NOT IN
		(SELECT p.P_ID
		FROM TBL_GROUPS_GOODS_PROPS ggp, TBL_PROPS p
		WHERE ggp.GRP_P_ID = p.P_ID AND ggp.GRP_GR_ID = @GRID));
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304003
natya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71,

план выполнения у вас ест?
смотрите план выполнения и вы сам будете исправит ошибки
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304018
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71Может укажете на какие кардинальные ошибки?
1) В теме не описаны исходные структуры;
2) В теме не описана сутьпроисходящего;
3) Код не обёрнут в соответствующий тег.

dimon71Можно ли существенно ускорить их выполнение? К примеру данный запрос выполняется секунд 20. Запросы идут потоком и в итоге все это долго.
Разбираться в этой некомементированной лапше нет никакого желания. Но навскидку весьма напоминает бред процедурного программиста, не понявшего суть SQL и плодящего итерационные циклы вместо одного простого запроса.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304173
HelenM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
natyaплан выполнения у вас есть?
смотрите план выполнения и вы сам будете исправит ошибки

Плюсую!
Иногда достаточно индексы добавить/убрать, чтобы запрос начал летать.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304180
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HelenMnatyaплан выполнения у вас есть?
смотрите план выполнения и вы сам будете исправит ошибки

Плюсую!
Иногда достаточно индексы добавить/убрать, чтобы запрос начал летать.

Интересуюсь, Сонечка, хдеж ты тут запрос то увидела?

У тредстартера тупая императивная процедура, которая на раз заменяется одним MERGE.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304191
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71,

Тут совет один — писать запросами а не курсорами.

Вот зачем тебе там курсор?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304199
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ув. автор топика, для простоты понимания, скажем так ,что Select * From [TableName] это типа как FOREACH
Т.е. вы в селекте пройдете по каждой строке соответсвующей условию автоматически. Ровно также как при инсерте и апдейте.

Т.е. вам надо для начала прочитать селект/инсерт/апдейт.
Затем оформление хранимок.
Затем начинать творить.

Хотя курсоры и проходят указанный диапазон построчно, нужны они совсем для другого.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304211
Фотография Сергей Викт.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71,

insert
select
и
update from вместо курсора..
А вообще правильно сказали выше, изучите базовые инструкции T-SQL:)
SELECT
UPDATE
INSERT
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304221
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор [ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304239
Фотография Сергей Викт.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор [ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние.
Согласен с вами)
А далее ещё:

<query hint> ::=
{
}
Но там всегда есть примеры, которые помогают осознать основные принципы, а далее просто время и разработка...
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304277
dimon71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет.
Покопаюсь.

Спасибо.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304285
Мистер Хенки
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет.
Покопаюсь.

Спасибо.
вам тут про оператор merge намекали, вот и начните чтение справочной информации с него
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304293
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы".По хорошему, все уже давно написано.
Синтаксические обозначения в Transact-SQL (Transact-SQL)
Расширенная форма Бэкуса — Наура
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304304
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
РБНФ; век живи--век учись. Спасибо коллега!
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304335
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71,

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304344
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Использование курсоров не так уж критически сказывается на быстродействии."
Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304368
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DirksDR,когда отработает расскажите нам, как там курсор сказывается на скорости выполнения, ок?
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 
if Object_id('tempdb..#t') is not null drop table #t 
create table #t (field int)

GO

 with myCTE as (
 select [n] = 1 
 union all 
 select [n] = [n] + 1 from myCTE
 where n < 1000000 
 )
  
insert into #t
select n from myCTE
option (maxrecursion  0 )
 

GO 

select * from #t


declare @f int 
declare myC cursor local forward_only  for select field from #t 
open myC 
fetch next from myC into @f
while @@fetch_status = 0 
begin
  select @f
  fetch next from myC into @f
end
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304371
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomileхочеться ==>хочется
ну почему тут нельзя редактировать посты ((((
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304412
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не .


К сожалению, только так и надо.
Эту процедуру надо заменить на два запроса insert update, или один merge.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304438
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор [ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние.Ну ладно, нормальный хелп, на русском языке, с примерами.

А эти "конструкции типа" обязательно надо изучить, так описываются синтаксические конструкции у всех производителей, и в учебниках, не только у микрософта. Эти конструкции на самом деле очень просты, всего лишь нужно понять, что озачают 3 вида скобок, многоточие и запятая.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304441
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile"Использование курсоров не так уж критически сказывается на быстродействии."
Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать.

А кто это писал?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304448
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileПо хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор [ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ] ввергают неокрепший разум в ужас и уныние.
Вы не поверите, но про то, как читать майкрософтовские хелпы", есть в самом хелпе - Transact-SQL Syntax Conventions (Transact-SQL)
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304449
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну вот же
DirksDRdimon71,

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304452
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile"Использование курсоров не так уж критически сказывается на быстродействии."
Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать.
Все зависит от конкретной задачи. И выигрывает всегда тот, кто знает больше способов. А не тот, у кого больше убеждений.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304456
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304458
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileПример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию.
Выберите любую задачу, где важен _порядок_ обработки записей
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304466
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
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; -- ну, тут надо сообразить
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304470
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304484
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу.
Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304493
dimon71
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Glory,

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

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

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

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

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

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

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

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

Спасибо.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304536
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomileну вот же
DirksDRdimon71,

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


Ааа...

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

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

На счет наглядности я бы тоже поспорил — запросы читать проще, сразу все ясно, и объективно это проще, декларативная логика запроса описывает, что надо сделать, а не как и что надо сделать, так что можно сказать в двп раза проще понимать.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304545
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?

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

Но я одну такую знаю — партионое списание товаров по FIFO или LIFO.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304560
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В данном случае наглядность и простота кода лучше.

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

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

Чтобы писать на SQL особенно -то много спец. Образования и не надо,
Надо только знать, что надо писать запросы везде, где только возможно, использовать индексы и выделять серверу память под кэш.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304572
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71В данном случае наглядность и простота кода лучше. Я, не имея специального образования, решил поставленную задачу с хорошим результатом.Конечно, нагладность и простота очень важны, и то, что задача решена - замечательно, но конкретно решение вашей задачи нагляднее и проще читается без курсоров.

Нужно комментарии на русском в процедуре записать на языке SQL в одном запросе, только и всего.
Просто для вас SQL не основной язык, вы к нему не привыкли, не чувствуете его.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304578
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу. За 7 лет практики не припомню таких "любых" задач где курсор был бы быстрее. Задачи где без курсора просто никак - да, много. А мы же говорим за _быстрее_, правда?

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

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

Умрет с появлением инструкции:
update ....
from ...
order by ...
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304586
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GloryCammomileВсе таки я бы хотел видеть конкретный пример. А не "любую" задачу.
Да легко
Обновить все записи в поле S нарастающим итогом по возростанию даты в поле D пределах одинаковых значений в поле G
Таблица
G - varchar
D - datetime
M - money
S - money
1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.
2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304596
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile2: Если 2005 , то " на глазок" есть "необычный апдейт", и мне пока кажется что он быстрее.
Он был еще в 2000. Только он не гарантирует порядок.
А именно про задачи завязанные на порядок обработки записей я и говорил.

Cammomile1: А в какой версии сервера, раз у пошел разговор? Если 2012 то быстрее будет с окнами.
Вы уже проверили это ?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304666
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.

"Только он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304672
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileЯ спросил у людей кот. попробовали, у меня 2012 нет =) Выигышь, говорят, в разы.
Ага. Слышал в вашего Карузо. Мне Рабинович напел

CammomileТолько он не гарантирует порядок." Это серьезный аргумент. Ну тогда вариант с курсором перезжает из категории "быстрее аналогичного апдейта" в категорию "единственное приемлимое решение", что тоже вне темы нашего обсуждения.
курсор не единственный способ получения такого нарастающего итога.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304697
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну там весьма авторитетный рабинович напел.

Так, вы сказали что есть случаи когда курсор быстрее аналогичного апдейта/селекта/ инсерта.
В вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304701
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileВ вашем примере НЕТ аналогичного апдейта/селекта/инсерта. А раз так, о чем разговор?
Что значит НЕаналогичный ? update from join он и африке update
Или вы знаете другие команды обновления ?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304736
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
update t set f = 1 where d in (1,2,3)



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

Код: sql
1.
2.
3.
4.
5.
6.
7.
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
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304750
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile аналогичный курсор который никак не может быть быстрее (типа того что делает автор топик
Смешной вы. Вы под аналогией понимаете давайте выполнять массовый апдейт в цикле по одной записи ?
Вы заявили, что все курсоры обязательно должны быть переписаны в запросы.
Даже у автора темы идут какие-то рассчеты и проверки. И вы даже не знаете, можно ли их осуществить в вашем update t set f = 1 where d in (1,2,3)
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304846
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimon71,

можно оптимизировать, надо избавиться от курсора
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304847
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304862
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О годная аналитика. Сейчас почитаем.

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

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

По мне так вполне надежно, не ?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304914
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CammomileМне кажется, что "не гарантирует порядка" больше спекуляция
1 - нет документированных случаев когда этот метод подвел бы
У вас есть документированный способ указания порядка обработки записей ?

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

Cammomile3 - конструкция успешно пережила все редакции сервера начиная с 2000 и все многочисленные багфиксы и апдейты
Разговор не про саму конструкцию, про гарантированный порядок.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304938
Фотография Shakill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304997
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304998
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Раз пошла такая пьянка- режь последний огурец !
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38304999
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот тут http://www.sqlservercentral.com/articles/T-SQL/68467/ чрезвычайно крутецкое исследование + методология безопасного использования "стремного апдейта" В случае TL;DR можно сразу листать к "The RULES"

Касаемо быстродействия
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305003
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Касаемо быстродействия
авторAnother choice is to use both the "Quirky Update" and the code that verifies it. Even if you copy the required data to a Temp Table (20 secs), do the update (6 secs), use the verification code (10 secs), and then update the original table (14 secs), it will still be almost 10 times faster than RBAR. On my machine, the Cursor method took almost 8 minutes to do just 1 running total. Running the full gambit of "Quirky Update" and "Verification" code including the creation of a separate verification table (which I'd only do for "in-place" updates) only took 50 seconds. Remember... that's on a million rows on a 7 year old non-server quality box.

ps
прошу прощения за 3 поста, это привычка нажимать ктрл+ентер чтобы сделать перенос строкив окне...
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305007
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cammomile+ методология безопасного использования "стремного апдейта"
Т.е. использование некого "быстрого" запроса оказывается возможно лишь при соблюдении "мер безопасности" ? И это должно сподвигнуть меня в сторону отказа от курсора ?
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305019
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Речь шла о быстродействии. Вот наглядный пример, где быстрый запрос + меры безопасности лучше курсора для типа задач который вы привели "в защиту" курсоров.

Также изначально было сказано одним из пользователей, что мол курсоры несильно влияют на скорость. Курсоры не могут несильно влиять на скорость, особенно на больших объемх данных. Хотяб потому, что в курсоре количество операций больше чем в цикле по таблице, коим является селект\апдейт. Об этом я пишу.

Также люди пишут, что апдейт с использованием новых функций в 2012 лучше курсора в разы.

Вот, собственно, весь хрен до копейки.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305021
Cammomile
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И я не агитирую за "отказ от курсоров" что вы мне тут приписываете на ровном месте! Каждому случаю -- подходящий инструмент.
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305045
Фотография SomewhereSomehow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Было уже много разговоров про курсоры, можно поискать по форуму. Лично я использую курсоры для выполнения exec процедур в цикле, иногда нужно. Хотя, даже в таких случаях, можно обойтись динамикой, но мне это кажется не очень удобным.

Касательно нарастающего итога, недавно на devcon разговаривал с докладчиком из sql cat, и что-то зашла речь про нарастающий итог. Я высказался что-то типа "хорошо, сейчас оконными функциями можно считать", на что на меня странно посмотрели и сказали, что "лучше держать его уже посчитанным", и, черт возьми, нельзя не согласиться - крайне быстрый способ =)
...
Рейтинг: 0 / 0
Можно ли существенно оптимизировать данную процедуру.
    #38305201
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SomewhereSomehowБыло уже много разговоров про курсоры, можно поискать по форуму. Лично я использую курсоры для выполнения exec процедур в цикле, иногда нужно. Хотя, даже в таких случаях, можно обойтись динамикой, но мне это кажется не очень удобным.

Касательно нарастающего итога, недавно на devcon разговаривал с докладчиком из sql cat, и что-то зашла речь про нарастающий итог. Я высказался что-то типа "хорошо, сейчас оконными функциями можно считать", на что на меня странно посмотрели и сказали, что "лучше держать его уже посчитанным", и, черт возьми, нельзя не согласиться - крайне быстрый способ =)
насчет "лучше держать уже подсчитанным" тоже пардон смешно. Случаи разные бывают.
Вообще бест практис - иметь итоги сгруппированные по дню. Ибо внутри дня нарастающие итоги по каждой транзакии иметь - overhead. А сгруппированные суммы до дня - легко считать хоть каким методом
...
Рейтинг: 0 / 0
57 сообщений из 57, показаны все 3 страниц
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Можно ли существенно оптимизировать данную процедуру.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]