La nueva propiedad "Lectura de filas reales" en los planes de ejecución (que en SQL Server Management Studio se muestra como "Número de filas leídas") fue una adición bienvenida a los sintonizadores de rendimiento. Es como tener un nuevo superpoder, poder distinguir el significado del Predicado de búsqueda frente al Predicado residual dentro de un operador de Búsqueda. Me encanta esto, porque puede ser muy importante para la consulta.
Veamos dos consultas, que estoy ejecutando en AdventureWorks2012. Son muy simples:uno enumera personas llamadas John S y el otro enumera personas llamadas J Smith. Como todas las buenas guías telefónicas, tenemos un índice en LastName, FirstName.
select FirstName, LastName from Person.Person where LastName like 'S%' and FirstName = 'John'; select FirstName, LastName from Person.Person where LastName = 'Smith' and FirstName like 'J%';
En caso de que tenga curiosidad, obtengo 2 filas de la primera y 14 filas de la segunda. En realidad no estoy tan interesado en los resultados, estoy interesado en los planes de ejecución.
Veamos qué está pasando. Abrí una copia anterior de SQL Sentry Plan Explorer y abrí mis planes uno al lado del otro. Por cierto, había ejecutado ambas consultas juntas, por lo que ambos planes estaban en el mismo archivo .sqlplan. Pero podría abrir el mismo archivo dos veces en PE y sentarlos felizmente uno al lado del otro en grupos de pestañas.
Estupendo. ¡Se ven iguales! Puedo ver que la búsqueda de la izquierda produce dos filas en lugar de catorce; obviamente, esta es la mejor consulta.
Pero con una ventana más grande, habría visto más información, y es una suerte haber ejecutado las dos consultas en el mismo lote.
Puede ver que se estimó que la segunda consulta, que produjo 14 filas en lugar de 2 filas, asumió el 80 % del costo. Si ejecutara las consultas por separado, cada una me mostraría el 100 %.
Ahora comparemos con la última versión de Plan Explorer.
Lo que me llama la atención de inmediato es la advertencia. Miremos un poco más de cerca.
La advertencia dice “La operación causó E/S residual. La cantidad real de filas leídas fue 2130, pero la cantidad de filas devueltas fue 2". Efectivamente, más arriba vemos "Filas reales leídas" que dice 2130 y Filas reales en 2.
¡Guau! Para encontrar esas filas, tuvimos que mirar a través de 2130?
Verá, la forma en que se ejecuta Seek es comenzar pensando en el Predicado Seek. Ese es el que aprovecha muy bien el índice, y que en realidad hace que la operación sea una Búsqueda. Sin un predicado Seek, la operación se convierte en Scan. Ahora, si se garantiza que este Predicado de búsqueda es como máximo una fila (como cuando tiene un operador de igualdad en un índice único), entonces tenemos una búsqueda de Singleton. De lo contrario, tenemos un escaneo de rango, y este rango puede tener un prefijo, un inicio y un final (pero no necesariamente un inicio y un final). Esto define las filas de la tabla que nos interesan para la búsqueda.
Pero "interesado en" no significa necesariamente "devuelto", porque es posible que tengamos más trabajo por hacer. Ese trabajo se describe en el otro Predicado, que a menudo se conoce como el Predicado Residual.
Ahora ese predicado residual podría estar haciendo la mayor parte del trabajo. Ciertamente está aquí:está filtrando las cosas de 2130 filas a solo 2.
El Range Scan comienza en el índice en "John S". Sabemos que si hay un “John S”, esta debe ser la primera fila que puede satisfacer todo. “Ian S” no puede. Entonces podemos buscar en el índice en ese punto para comenzar nuestro Range Scan. Si miramos el Plan XML podemos ver esto explícitamente.
Tenga en cuenta que no tenemos un prefijo. Eso se aplica cuando tiene una igualdad en la primera columna dentro del índice. Solo tenemos StartRange y EndRange. El inicio del rango es "Mayor o igual" (GE) ScanType, en el valor "S, John" (las referencias de columna fuera de la pantalla son Apellido, Nombre), y el final del rango es "Menor que" ( LT) el valor T. Cuando el escaneo llega a T, está listo. Nada más que hacer. El Seek ahora ha completado su Range Scan. ¡Y en este caso, devuelve 2130 filas!
Excepto que en realidad no devuelve 2130 filas, solo lee 2130 filas. Se leen nombres como Barry Sai y Ken Sánchez, pero solo se devuelven los nombres que satisfacen la siguiente verificación:el predicado residual que asegura que el nombre sea John.
La entrada Lectura de filas reales en las propiedades del operador Búsqueda de índice nos muestra este valor de 2130. Y aunque es visible en versiones anteriores de Plan Explorer, no recibimos una advertencia al respecto. Eso es relativamente nuevo.
Nuestra segunda consulta (buscar a J Smith) es mucho más agradable, y hay una razón por la que se estimó que era más de 4 veces más barata.
Aquí sabemos exactamente el Apellido (Smith), y el Escaneo de Rango está en el Nombre (J%).
Aquí es donde entra en juego el Prefijo.
Vemos que nuestro Prefijo es un operador de Igualdad (=, ScanType=”EQ”), y que LastName debe ser Smith. Ni siquiera hemos considerado el Inicio o el Final del rango todavía, pero el Prefijo nos dice que el rango está incluido dentro de la parte del índice donde LastName es Smith. Ahora podemos encontrar las filas>=J y
Todavía hay un predicado residual aquí, pero esto solo es para asegurarse de que "LIKE J%" se pruebe realmente. Si bien nos parece intuitivo que "LIKE J%" es exactamente equivalente a ">=J and
Antes del Service Pack 3 de SQL Server 2012, no teníamos esta propiedad, y para tener una idea de la diferencia entre la lectura de filas reales y las filas reales, necesitaríamos usar el indicador de rastreo 9130. Aquí están esos dos planes con ese TF encendido:
Puede ver que esta vez no hay advertencia, porque el operador Seek está devolviendo las 2130 filas. Creo que si está usando una versión de SQL Server que admite esta lectura de filas reales, debería dejar de usar el indicador de rastreo 9130 en sus investigaciones y, en su lugar, comenzar a buscar las advertencias en Plan Explorer. Pero, sobre todo, comprenda cómo hacen su trabajo sus operadores, porque entonces podrá interpretar si está satisfecho con el plan o si necesita tomar medidas.
En otra publicación, le mostraré una situación en la que puede preferir que las lecturas de filas reales sean más altas que las filas reales.
@rob_farley
