Hacer los motores de bases de datos que no sean de SQL Server se comportan de esta manera?

Question

Tengo un procedimiento almacenado que es algo como esto (pseudo código)

  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

Todo funcionó bien durante mucho tiempo. De repente, la consulta empezó a correr para siempre si param4 era 'Y'. Cambiar el código para esto:

  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

Y se ejecuta de nuevo dentro de los parámetros esperados (15 segundos o menos para 40.000 registros). Esto es con SQL Server 2005. La esencia de mi pregunta es específica de este particular "característica" a SQL Server, o se trata de una característica común entre RDBMS' en general que:

1. Las consultas que corrió bien durante dos años acaba de dejar de trabajar ya que los datos crece.
2. El "nuevo" plan de ejecución destruye la capacidad del servidor de base de datos para ejecutar la consulta, aunque lógicamente equivalentes a carreras alternativas bien?

Esto puede parecer como una diatriba en contra de SQL Server, y supongo que en cierta medida lo es, pero la verdad es que quieren saber si los demás experimentan este tipo de realidad con Oracle, DB2 o cualquier otro RDBMS. A pesar de que tengo algo de experiencia con los demás, sólo he visto este tipo de volumen y complejidad en SQL Server, así que estoy ansioso por ver si otros con grandes bases de datos complejas tienen experiencia similar en otros productos.

Answer 1

No podría ser un par de causas

1) son estadísticas hasta la fecha?

2) usted podría estar sufriendo de descubrimiento de parámetros

Por cierto, para este tipo de cosas

donde (param2 es nulo o param2 = SOME_VIEW.Somecolumn2)

Tome un vistazo a ¿utiliza columna = @ Param O @Param IS NULL en su cláusula WHERE? No, no realice

Answer 2

Me imagino esta instancia específica del problema, y ??todas las condiciones que dan lugar a que esto ocurra son específicas de servidor SQL - probablemente incluso la edición. (Por ejemplo SQL Server 2008 se comportaría de manera diferente.)

Pero esto es una "característica" general de los optimizadores de consulta. Se ven en la consulta y tratar de hacer una conjetura informada en cuanto a lo que va a ejecutar el más rápido. Como usuarios, tenemos poco control directo si los elige Optimizer (digamos) un recorrido de índice o un búsqueda de índice, pero pueden influir de manera indirecta, proporcionando formas alternativas de expresar lo mismo, para ver si es que invoca mejoraron el tiempo de ejecución.

Si no ha habido ningún otro cambio de esquema que podrían influir en la consulta, a continuación, comprobar que las estadísticas de índices se actualizan. Utilizamos un trabajo por lotes semanalmente para hacer esto.