La ejecución de la misma solicitud de C # VS SSMS proporciona un tiempo de ejecución diferente

12

Tengo una solicitud como esta

SELECT 
[EstimateId], 
[CreationUserId], 
[EstimateStatusValueId], 
[LanguageId], 
[LocationId], 
[EstimatorUserId], 
[FilterUnitSystemTypeId], 
[EstimateNumber], 
[RevisionNumber], 
[CreationDate], 
[ModificationDate], 
[ProjectDescription], 
[IsBsdq], 
[ClosingDate], 
[ClosingTime], 
[ClosingUpdatedOn], 
[DeadLineDate], 
[IsReceived], 
[Inclusion], 
[Exclusion], 
[Misc], 
[Note], 
[WorkDeadLines], 
[Comments], 
[Validity], 
[PlansLocation], 
[PlansReceivedFrom], 
[Price]
FROM [Estimate].[Estimates] 
ORDER BY [ClosingDate] ASC, [ClosingTime] ASC

Cuando ejecuto esta consulta en SSMS obtengo un tiempo de ejecución de 953 ms, pero cuando ejecuto esta consulta desde una consulta Linq en mi C # obtengo un tiempo de ejecución de 1813 ms.

La consulta Linq utiliza el "proveedor de datos de .Net SqlClient" y se emite contra EntityFramework (archivo EDMX). ¿Esto puede ser un problema?

¿Alguien sabe por qué tengo una gran diferencia entre los tiempos de ejecución de esas solicitudes que son las mismas pero se ejecutan desde un contexto diferente en la misma base de datos?

Verifiqué todos los planes de ejecución de ambas solicitudes y utilizan el mismo índice para satisfacer sus respectivas consultas.

Para ver el plan de ejecución de la solicitud de C #, utilizo el generador de perfiles SQL para capturar el evento Mostrar plan XML y lo comparo con el de SSMS y ambos son iguales.

sql-server-2008 database-tuning Nico
fuente
solo una pequeña pregunta: ¿por qué selecciona todos los datos de la tabla sin ninguna condición de búsqueda? ¿Realmente necesita todos los datos en la aplicación sin ningún filtro?
Marian
Sí, esta es una característica que necesito, pero esta característica no se usará con frecuencia. Sé que no es óptimo emitir una consulta grande sin la cláusula where.
Nico
De todos modos, mi preocupación no es la solicitud en sí, sino la diferencia entre los tiempos de ejecución. Le muestro esta consulta pero todas las consultas dan resultados similares. Por qué ?
Nico

Respuestas:

6

¿Es esto consistente una y otra vez?

Veo una diferencia de CPU que podría ser el tiempo de compilación. ¿Hay alguna configuración de LINQ que afecte esto?

Editar:

  • Capture los planes en Profiler
  • ¿Estás seguro de que el SQL es el mismo en Profiler ?
gbn
fuente
Sí, es consistente una y otra vez. No sé para la configuración de linq. pero encontré este enlace codeproject.com/KB/cs/linqsql2.aspx
Nico
Puede ver el plan en la imagen de arriba para ambas consultas. Sí, estoy seguro de que el SQL es el mismo en el generador de perfiles. Las aplicaciones SQL, Profiler, SSMS y C # están alojadas en mi computadora para fines de desarrollo.
Nico
Capture el plan real en XML desde Profiler. No de la caché. Tiene diferentes respuestas, pero muestra un plan diferente = tal vez se muestra el plan incorrecto anterior
gbn
3

Deberá mirar los planes de ejecución para las dos consultas y ver en qué se diferencian.

mrdenny
fuente
acabo de editar mi publicación ... y ya verifico que ambas consultas usan el mismo plan.
Nico
1
Solo agrego el evento que me dijiste al generador de perfiles y es lo mismo que mi última solicitud que publiqué en mi pregunta. Tengo los mismos planes ... cualquier otra idea ...
Nico
2
Todo se ve bien. Lo único que podría explicarlo sería si la aplicación .NET no recibe los datos lo suficientemente rápido. El tiempo reportado en SQL Profiler incluye la cantidad de tiempo para transferir los datos del servidor al cliente. Entonces, si el cliente no descarga todo lo suficientemente rápido, el tiempo de ejecución informado será más largo.
mrdenny
2
Luego se reduce a lo que la aplicación está haciendo con los datos, y cómo está leyendo los datos de la base de datos.
mrdenny
3
En apoyo a la respuesta de mrdenny, agregaría que probé una consulta en 3 clientes SQL diferentes y sus tiempos informados fueron todos diferentes, aunque las estadísticas de IO y la ejecución de los planes fueron idénticos. Todo fue causado por la forma interna de cómo los clientes trataban los datos. Creo que puede obtener resultados de tiempo diferentes al enviarlos a un archivo, a la cuadrícula en Management Studio o al texto. De todos modos, por lo que recuerdo, la documentación decía que SQL siempre será más rápido que LINQ to SQL, por lo que esto no es una sorpresa :-).
Marian