2013-07-31 2 views
0

Это моя хранимая процедура, для выполнения которой требуется некоторое время, даже если она работает с локальной базой данных.Нужны советы по оптимизации хранимой процедуры SQL Server

Просьба предложить изменения в целях повышения производительности

BEGIN TRY 
     DECLARE @COUNTRY_CD INT 
     SET @COUNTRY_CD =(SELECT COUNTRY_CD FROM COUNTRY WHERE COUNTRY_DESC = LTRIM(RTRIM(@COUNTRY_DESC))) 
     DECLARE @COMPANNY_CD INT 
     SET @COMPANNY_CD =(SELECT COMPANY_CD FROM COMPANY WHERE COMPANY_DESC = LTRIM(RTRIM(@COMPANY_DESC))) 
    BEGIN TRANSACTION 
     DELETE FROM PACK 
     WHERE COUNTRY_CD = @COUNTRY_CD 
       AND COMPANY_CD = @COMPANNY_CD 
       AND PACK_DESC = LTRIM(RTRIM(@PACK_DESC)) 
    COMMIT TRANSACTION 
END TRY 
BEGIN CATCH 
    IF(@@TRANCOUNT > 0) 
     ROLLBACK TRANSACTION 
    DECLARE @ErrMsg nvarchar(4000), 
      @ErrSeverity int 
    SELECT @ErrMsg = ERROR_MESSAGE(),@ErrSeverity = ERROR_SEVERITY() 
    RAISERROR(@ErrMsg, @ErrSeverity, 1) 
END CATCH 
+1

Что вы ** таблица stru ctures ** (столбцы, типы данных)? И какие индексы у вас есть на этих таблицах? Сколько строк данных в этих таблицах? –

ответ

0

Трудно сказать точно, не зная больше о вашей схеме базы данных. Несколько первоначальных идей могут заключаться в том, чтобы сразу очистить переменные * _DESC, а не делать LTRIM и RTRIM в предложении WHERE. Возможно, рассмотрим или добавим индекс в таблицу PACK, которая включает COUNTRY_CD/COMPANY_CD (хотя и не описание, если предположить, что это длинный текст строки. Я бы подумал, что КОМПАНИЯ и СТРАНА - довольно маленькие таблицы, но, надеюсь, у вас есть соответствующие индексы в этих полях. Кроме того, стоит попробовать, чтобы присоединиться к этим таблицам, в УДАЛИТЬ, а не делать Lookups раньше времени.

-- clenaup variables 
-- these should be new vars, not input parms 
SELECT @COUNTRY_DESC = LTRIM(RTRIM(@COUNTRY_DESC)) 
    ,@COMPANY_DESC = LTRIM(RTRIM(@COMPANY_DESC)) 
    ,PACK_DESC = LTRIM(RTRIM(@PACK_DESC)) 

-- delete 
DELETE PACK 
FROM PACK 
JOIN COUNTRY ON PACK.COUNTRY_CD = COUNTRY.COUNTRY_CD 
JOIN COMPANY ON PACK.COMPANY_CD = COMPANY.COMPANY_CD 
WHERE COUNTRY.COUNTRY_DESC = @COUNTRY_DESC 
AND COMPANY.COMPANY_DESC = @COMPANY_DESC 
AND PACK.PACK_DESC = @PACK_DESC 
+0

привет, спасибо за ответ. Попробовал ваше предложение, но он также принимал в то же время выполнение – Rohaan

+0

спасибо..несколько незначительных изменений он помог. – Rohaan

0

Try щелкнув правой кнопкой мыши в пределах хранимой процедуры и проверить стоимость Executon плана. Вы можете увидеть, как будет «дорого» ваш SP.

В случае необходимости вы можете попробовать

https://stackoverflow.com/a/797968/1504882

1

Попытаемся оценить значения переменных @COUNTRY_CD и @COMPANNY_CD в отдельном прок и передать их в качестве I/параметр р к этому proc и посмотреть, помогает ли это. Я видел этот вопрос в прошлом, и решение , которое я только что упомянул, решило проблему.

0

Убедитесь COMPANY индексируется на company_cd, СТРАНА на country_cd и ПАК на company_cd, country_cd, pack_desc.

Удаление из большой таблицы займет некоторое время без правильного индекса.

+0

Привет, я создал индекс по ПАК таблицы, как это 'CREATE некластеризованного индекса [idx_pack_company_country_pack_desc] ВКЛ [DBO]. [ПАК] ( \t [PACK_CD] ASC ) ВКЛЮЧИТЬ (\t [COMPANY_CD], \t [PACK_DESC] , \t [COUNTRY_CD]) С (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ВЫКЛ, SORT_IN_TEMPDB = ВЫКЛ, DROP_EXISTING = OFF ОНЛАЙН = ВЫКЛ, ALLOW_ROW_LOCKS = ON ALLOW_PAGE_LOCKS = ВКЛ) ВКЛ [PRIMARY] GO' правильно ли это? и поскольку company_cd и country_cd являются первичными ключами, я думаю, что они уже проиндексированы .. – Rohaan

Смежные вопросы