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

Откуда:
Сообщений: 172
Доброго вечера, уважаемые!

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

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

-- Переносит характеристики товара по умолчанию на товар
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));


Сообщение было отредактировано: 20 июн 13, 11:24
19 июн 13, 22:46    [14456683]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
natya
Member [заблокирован]

Откуда: Азербайджан, Баку
Сообщений: 347
dimon71,

план выполнения у вас ест?
смотрите план выполнения и вы сам будете исправит ошибки
19 июн 13, 22:55    [14456720]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Akina
Member

Откуда: Зеленоград, Москва, Россия
Сообщений: 20603
dimon71
Может укажете на какие кардинальные ошибки?

1) В теме не описаны исходные структуры;
2) В теме не описана сутьпроисходящего;
3) Код не обёрнут в соответствующий тег.

dimon71
Можно ли существенно ускорить их выполнение? К примеру данный запрос выполняется секунд 20. Запросы идут потоком и в итоге все это долго.

Разбираться в этой некомементированной лапше нет никакого желания. Но навскидку весьма напоминает бред процедурного программиста, не понявшего суть SQL и плодящего итерационные циклы вместо одного простого запроса.
19 июн 13, 23:50    [14456958]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
HelenM
Member

Откуда: Москва
Сообщений: 53
natya
план выполнения у вас есть?
смотрите план выполнения и вы сам будете исправит ошибки


Плюсую!
Иногда достаточно индексы добавить/убрать, чтобы запрос начал летать.
20 июн 13, 09:09    [14457536]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
aleks2
Guest
HelenM
natya
план выполнения у вас есть?
смотрите план выполнения и вы сам будете исправит ошибки


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


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

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

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

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

Вот зачем тебе там курсор?
20 июн 13, 09:24    [14457596]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Ув. автор топика, для простоты понимания, скажем так ,что Select * From [TableName] это типа как FOREACH
Т.е. вы в селекте пройдете по каждой строке соответсвующей условию автоматически. Ровно также как при инсерте и апдейте.

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

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

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

insert
select
и
update from вместо курсора..
А вообще правильно сказали выше, изучите базовые инструкции T-SQL:)
SELECT
UPDATE
INSERT
20 июн 13, 09:41    [14457662]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор
[ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ]
ввергают неокрепший разум в ужас и уныние.
20 июн 13, 09:47    [14457694]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Сергей Викт.
Member

Откуда: Москва
Сообщений: 888
Cammomile
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор
[ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ]
ввергают неокрепший разум в ужас и уныние.

Согласен с вами)
А далее ещё:

<query hint> ::=
{
}
Но там всегда есть примеры, которые помогают осознать основные принципы, а далее просто время и разработка...
20 июн 13, 09:53    [14457744]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
dimon71
Member

Откуда:
Сообщений: 172
Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет.
Покопаюсь.

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

Откуда: канализация
Сообщений: 6615
dimon71
Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не выйдет.
Покопаюсь.

Спасибо.

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

Откуда: Москва
Сообщений: 9406
Cammomile
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы".
По хорошему, все уже давно написано.
Синтаксические обозначения в Transact-SQL (Transact-SQL)
Расширенная форма Бэкуса — Наура
20 июн 13, 10:28    [14458019]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
РБНФ; век живи--век учись. Спасибо коллега!
20 июн 13, 10:34    [14458068]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
DirksDR
Member

Откуда: Пермь
Сообщений: 340
dimon71,

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).
20 июн 13, 10:54    [14458269]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

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

Откуда:
Сообщений: 1214
DirksDR,когда отработает расскажите нам, как там курсор сказывается на скорости выполнения, ок?
 
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
20 июн 13, 11:16    [14458485]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Cammomile
хочеться
==>хочется
ну почему тут нельзя редактировать посты ((((
20 июн 13, 11:17    [14458494]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
dimon71
Cammomile, и другие уважаемые форумчане. Большое спасибо за советы.
Все понял. Пошел исправляться.
Насчет замены нараз всего этого одним запросом, думаю ничего не .



К сожалению, только так и надо.
Эту процедуру надо заменить на два запроса insert update, или один merge.
20 июн 13, 11:38    [14458649]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31442
Cammomile
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор
[ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ]
ввергают неокрепший разум в ужас и уныние.
Ну ладно, нормальный хелп, на русском языке, с примерами.

А эти "конструкции типа" обязательно надо изучить, так описываются синтаксические конструкции у всех производителей, и в учебниках, не только у микрософта. Эти конструкции на самом деле очень просты, всего лишь нужно понять, что озачают 3 вида скобок, многоточие и запятая.
20 июн 13, 11:44    [14458705]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Cammomile
"Использование курсоров не так уж критически сказывается на быстродействии."
Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать.


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

Откуда:
Сообщений: 104760
Cammomile
По хорошему, нам нужен отдельный faq по теме "как читать майкрософтовские хелпы". По своему опыту скажу, что конструкции типа
автор
[ <FOR Clause>]
[ OPTION ( <query_hint> [ ,...n ] ) ]
ввергают неокрепший разум в ужас и уныние.

Вы не поверите, но про то, как читать майкрософтовские хелпы", есть в самом хелпе - Transact-SQL Syntax Conventions (Transact-SQL)
20 июн 13, 11:48    [14458737]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Cammomile
Member

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

Нет информации о размерах таблицы. Но 20 сек даже для миллиона записей много.
Вряд ли в справочние товаров у Вас больше.
Проверьте наличие и использование индексов.
Использование курсоров не так уж критически сказывается на быстродействии.
Зато намного наглядней алгоритм(скрипт).
20 июн 13, 11:48    [14458741]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли существенно оптимизировать данную процедуру.  [new]
Glory
Member

Откуда:
Сообщений: 104760
Cammomile
"Использование курсоров не так уж критически сказывается на быстродействии."
Вот за такое хочеться взять и у...бедить так больше никогда-никогда не писать.

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

Откуда:
Сообщений: 1214
Пример когда селект\инсерт\апдейт в курсоре быстрее чем без курсора в студию.
20 июн 13, 11:55    [14458792]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить