Las lecturas de la base de datos varían drásticamente en una consulta con índices

Question

Tengo una consulta que tiene los índices apropiados y se muestra en el plan de consulta con un subárbol estimado de alrededor de 1,5. El plan muestra una búsqueda de índice, seguida de búsqueda clave, lo que está bien para una consulta que espera devolver 1 fila de un conjunto de entre 5 y 20 filas (es decir, la búsqueda de índice debe encontrar entre 5 y 20 filas, y luego 5-20 Principales búsquedas, deberíamos devolver 1 fila).

Cuando se ejecuta de forma interactiva, la consulta se devuelve casi de inmediato. Sin embargo, DB rastrea los tiempos de ejecución de este show matutino en vivo (una aplicación web) que varían enormemente; típicamente la consulta está tomando < 100 DB Reads, y efectivamente 0 runtime ... pero estamos obteniendo algunas ejecuciones que consumen> 170,000 DB Reads, y runtime hasta 60s (mayor que nuestro valor de timeout).

¿Qué podría explicar esta variación en las lecturas de disco? Intenté comparar consultas de forma interactiva y utilizar planes de Ejecución real a partir de dos ejecuciones paralelas con valores de filtro tomados de ejecuciones rápidas y lentas, pero de forma interactiva no muestran ninguna diferencia en el plan utilizado.

También traté de identificar otras consultas que podrían estar bloqueando esta, pero no estoy seguro de que esto afecte tanto a las lecturas DB ... y en cualquier caso esta consulta tendía a ser la peor para el tiempo de ejecución en mi rastro registros

Actualización: He aquí una muestra del plan que se produce cuando la consulta se ejecuta de forma interactiva:

favor ignore el texto 'índice perdido'. Es es cierto que los cambios en los índices actuales podrían permitir una consulta más rápida con menos búsquedas, pero ese no es el problema aquí (ya hay índices adecuados). Este es un plan de ejecución real, donde vemos cifras como Número real de filas. Por ejemplo, en la búsqueda de índice, el número real de filas es 16 y el costo de E/S es 0.003. El costo de E/S es el mismo en Key Lookup.

Actualización 2: Los resultados de la traza para esta consulta son:

exec sp_executesql N'select [...column list removed...] from ApplicationStatus where ApplicationGUID = @ApplicationGUID and ApplicationStatusCode = @ApplicationStatusCode;',N'@ApplicationGUID uniqueidentifier,@ApplicationStatusCode bigint',@ApplicationGUID='ECEC33BC-3984-4DA4-A445-C43639BF7853',@ApplicationStatusCode=10 

La consulta se construye utilizando la clase Gentle.Framework SqlBuilder, que construye consultas parametrizadas como este:

SqlBuilder sb = new SqlBuilder(StatementType.Select, typeof(ApplicationStatus)); 
sb.AddConstraint(Operator.Equals, "ApplicationGUID", guid); 
sb.AddConstraint(Operator.Equals, "ApplicationStatusCode", 10); 
SqlStatement stmt = sb.GetStatement(true); 
IList apps = ObjectFactory.GetCollection(typeof(ApplicationStatus), stmt.Execute()); 

Answer 1

¿Se podrían eliminar los datos de la memoria caché? Esa puede ser una explicación de por qué con una memoria caché activa (datos que ya están en la memoria), las lecturas grabadas son muy bajas ... y luego, cuando los datos ya no están en la RAM, las lecturas aumentarían, ya que tiene que leerlo fuera del disco. de nuevo.

Solo una idea para hacer que las cosas se muevan.

Answer 2

Ejecute el generador de perfiles para ver si las estadísticas se están actualizando al mismo tiempo. O simplemente para ver qué más está sucediendo.

Además, agregue la consulta SQL y el código del cliente.

Pensamientos:

• Suena como sus "5-20" filas podrían ser mucho más que eso
• Con un plan mal/descubrimiento de parámetros se obtendría un rendimiento consistentemente mal
• ¿Cómo puede escribe suceden en esta tabla: lo suficiente para actualizar las estadísticas?
• ¿Hay algún problema con el tipo de datos? (por ejemplo, concatenar parámetros e introducir una conversión de tipo de datos)