Хранимая процедура; Вставить медлительность

Question

У меня SP, который занимает 10 секунд, чтобы работать около 10 раз (около секунды при каждом запуске). Платформа - asp .net, а сервер - SQL Server 2005. Я проиндексировал таблицу (не на ПК также), и это не проблема. Некоторые предостережения:

• usp_SaveKeyword не является проблемой. Я прокомментировал весь SP, и это не имело значения.
• Я установил @SearchID равным 1, и время было значительно сокращено, в среднем на транзакцию ушло всего около 15 мс.
• Я закомментировал всю хранимую процедуру, кроме вставки в tblSearches, и странным образом потребовалось больше времени для выполнения.

Есть идеи о том, что может происходить?

set ANSI_NULLS ON

go

ALTER PROCEDURE [dbo].[usp_NewSearch]

  @Keyword VARCHAR(50),

  @SessionID UNIQUEIDENTIFIER,

  @time SMALLDATETIME = NULL,

  @CityID INT = NULL

AS

BEGIN

  SET NOCOUNT ON;

  IF @time IS NULL SET @time = GETDATE();



  DECLARE @KeywordID INT;

  EXEC @KeywordID = usp_SaveKeyword @Keyword;

  PRINT 'KeywordID : '

  PRINT @KeywordID

  DECLARE @SearchID BIGINT;     

  SELECT TOP 1 @SearchID = SearchID

    FROM tblSearches 

   WHERE SessionID = @SessionID

     AND KeywordID = @KeywordID;



  IF @SearchID IS NULL BEGIN

        INSERT INTO tblSearches

              (KeywordID, [time], SessionID, CityID)

         VALUES

              (@KeywordID, @time, @SessionID, @CityID)

        SELECT Scope_Identity();

  END

  ELSE BEGIN

        SELECT @SearchID

  END



END

Answer 1

Включите «Показать примерный план выполнения» в SQL Management Studio - где план выполнения показывает, как вы проводите время? Он поможет вам с эвристикой, используемой для оптимизации запроса (или не в этом случае). Как правило, на «толстых» линиях следует сосредоточить внимание - они генерируют большое количество операций ввода-вывода.

К сожалению, даже если вы сообщите нам схему таблицы, только вы сможете увидеть, как на самом деле SQL решил оптимизировать запрос. И последнее: есть ли у вас кластерный индекс в tblSearches?

Answer 2

Почему вы используете top 1 @SearchID вместо max (SearchID) или where exists в этом запросе? top требует, чтобы вы запустили запрос и получили первую строку из набора результатов. Если результирующий набор большой, это может потребовать довольно много ресурсов, прежде чем вы получите окончательный результирующий набор.

SELECT TOP 1 @SearchID = SearchID    
  FROM tblSearches    
 WHERE SessionID = @SessionID     
   AND KeywordID = @KeywordID;

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

select @SearchID = isnull (max (SearchID), -1)
  from tblSearches
 where SessionID = @SessionID
   and KeywordID = @KeywordID

Это должно быть довольно эффективно и (если я что-то упускаю) семантически эквивалентно.

Answer 3

1. Что такое кластеризованный индекс в tblSearches? Если кластерный индекс не относится к первичному ключу, база данных может тратить много времени на переупорядочение.
2. Сколько еще у вас индексов?
3. У вас есть триггеры?
4. Где в плане выполнения указано время, проведенное?

Answer 4

Триггеры!

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