Consulta lenta ColdFusion, SQL Server, depende del espacio en blanco

sql-server performance

Question

Tenemos un problema, estamos llamando a SQL Server 2005 desde ColdFusion 9. No puedo publicar la consulta original, pero no es el foco del problema, he publicado la combinación relevante de las cosas que causan el problema.

Tenemos una consulta que es una versión mucho más complicada de la siguiente consulta de ejemplo, donde la columna something es una clave principal. El parámetro de valor no está cambiando. Esta consulta, por alguna extraña razón que no podemos entender, toma casi 20 segundos para ejecutarse ...

<cfquery result="q" datasource="dsn">
SELECT something
FROM somewhere
WHERE something = <cfqueryparam cfsqltype="cf_sql_integer" value="#value#"/>
</cfquery>

Observe si usted, resalte la última línea del código fuente anterior, hay un espacio después de la etiqueta cfqueryparam.

La siguiente consulta, completamente diferente, estoy seguro de que puede verlo por sí mismo, tarda 15 ms en ejecutarse.

<cfquery result="q" datasource="dsn">
SELECT something
FROM somewhere
WHERE something = <cfqueryparam cfsqltype="cf_sql_integer" value="#value#"/>
</cfquery>

No hay espacios después del cfqueryparam. Sin embargo, agregar dos espacios al final da 15 ms también. Si luego volvemos a un espacio al final, obtendremos el resultado en aproximadamente 20 segundos nuevamente.

Hemos examinado los registros del controlador de base de datos entre Java y SQL Server y nada parece fuera de lo común. ¿Qué podría estar pasando aquí?

Editar

Hemos ejecutado perfiles en SQL Server y muestra que para la consulta con el espacio único está utilizando un plan de ejecución en caché diferente del que tiene cero o múltiples espacios. SQL Server almacena en caché los planes de ejecución para las consultas. También utiliza la consulta literal completa como el identificador. Entonces, cuando estábamos enviando las otras consultas, se está utilizando un plan de ejecución diferente.

Promover

Parece que uno de los planes de ejecución busca un índice incorrecto en una de las selecciones secundarias, no está claro por qué SQL Server decidió este plan de ejecución alternativo o por qué parece que uno de los índices es incorrecto.

Seguir

Para cualquier persona interesada en lo que podría haber causado el plan de ejecución incorrecto, la pregunta de seguimiento se publicó aquí: SQL Server 2005 almacenó en caché un plan de ejecución que nunca podría funcionar

Answer 1

Esto es posiblemente un síntoma de algo que surgió en los foros de Railo el otro día (extraña coincidencia).

Existe la posibilidad de que la naturaleza del valor del parámetro utilizado cuando se ejecutó por primera vez la versión lenta de la consulta causó la creación de un plan de ejecución que era "conveniente" para ese valor específico, pero para valores posteriores más típicos, el plan era menor que ideal. Por el contrario, cuando se ejecutó por primera vez la segunda consulta, el valor pasado como el parámetro era más típico de cómo se llama a la consulta, por lo que el plan de ejecución se ajusta mejor a la mayoría de los otros valores.

Personalmente, no he visto que esto ocurra, pero lo he leído muchas veces. Y suena como lo que estás viendo.

Si es posible, pruebe esto claramente con el caché de SQL Server, luego vuelva a ejecutar las consultas con el valor que causó la compilación del plan "malo", y debería ver un comportamiento similar.

Esta no es una solución, pero demostrará que podría ser la causa, y le permitirá abordar cuál podría ser la causa subyacente de las discrepancias en los planes para diferentes valores.

Esta experimentación obviamente se basa en saber cuáles eran los valores de param en el momento en que se llamaron por primera vez las consultas, lo cual es ... bueno, sería fortuito para ti si las conocieras.