Действуют ли так же движки баз данных, кроме SQL Server? - PullRequest
0 голосов
/ 28 мая 2010

У меня есть хранимая процедура, которая выглядит примерно так (псевдокод)

  storedprocedure param1, param2, param3, param4
  begin
     if (param4 = 'Y')
         begin
             select * from SOME_VIEW order by somecolumn
         end
     else if (param1 is null)
          begin
             select * from SOME_VIEW
                where (param2 is null or param2 = SOME_VIEW.Somecolumn2)
                and (param3 is null or param3 = SOME_VIEW.SomeColumn3) 
             order by somecolumn
          end
     else
          select somethingcompletelydifferent
     end

Все хорошо в течение долгого времени. Внезапно, запрос начал выполняться навсегда, если param4 было 'Y'. Изменение кода на это:

  storedprocedure param1, param2, param3, param4
  begin
     if (param4 = 'Y')
         begin
             set param2 = null
             set param3 = null
         end
     if (param1 is null)
          begin
             select * from SOME_VIEW
                where (param2 is null or param2 = SOME_VIEW.Somecolumn2)
                and (param3 is null or param3 = SOME_VIEW.SomeColumn3) 
             order by somecolumn
          end
     else
          select somethingcompletelydifferent

И он снова запускается в ожидаемых параметрах (15 секунд или около того для 40 000 записей). Это касается SQL Server 2005. Суть моего вопроса - это особая «особенность», специфичная для SQL Server, или это обычная особенность СУБД:

  1. Запросы, которые выполнялись в течение двух лет, просто перестают работать по мере роста данных.
  2. «Новый» план выполнения разрушает способность сервера базы данных выполнять запрос, даже если логически эквивалентная альтернатива работает нормально?

Это может показаться бессмысленным в отношении SQL Server, и я полагаю, что в какой-то степени это так, но я действительно хочу знать, сталкиваются ли другие с такой реальностью с Oracle, DB2 или любой другой RDBMS. Хотя у меня есть некоторый опыт работы с другими, я видел такой объем и сложность только в SQL Server, поэтому мне любопытно, имеют ли опыт работы другие продукты с большими сложными базами данных в других продуктах.

Ответы [ 2 ]

4 голосов
/ 28 мая 2010

Может быть несколько причин

1) статистика актуальна?

2) вы можете страдать от перехвата параметров

Кстати, для такого рода вещей

где (param2 равен нулю или param2 = SOME_VIEW.Somecolumn2)

Взгляните на Используете ли вы Column = @ Param ИЛИ @Param NULL в предложении WHERE? Не, это не выполняет

1 голос
/ 28 мая 2010

Я бы вообразил этот конкретный случай проблемы, и все условия, которые приводят к этому, специфичны для сервера SQL - возможно, даже для редакции. (Например, SQL Server 2008 будет вести себя по-другому.)

Но это общая «особенность» оптимизаторов запросов. Они смотрят на ваш запрос и пытаются сделать обоснованное предположение о том, что будет выполняться быстрее всего. Как пользователи, мы не имеем прямого прямого контроля, если оптимизатор выбирает (скажем) сканирование индекса или поиск индекса, но может косвенно влиять на него, предлагая альтернативные способы выражения того же самого, чтобы увидеть, вызывает ли это улучшенное время выполнения.

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

...