Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:SQL Server
Azure SQL Managed Instance
La E/S de una instancia del Motor de base de datos de SQL Server incluye lecturas lógicas y físicas. Una lectura lógica se produce cada vez que el motor de base de datos solicita una página de la caché del búfer, también conocida como grupo de búferes. Si la página no está actualmente en la memoria caché del búfer, una lectura física copia primero la página del disco en la memoria caché.
Las solicitudes de lectura generadas por una instancia del motor de base de datos se controlan mediante el motor relacional y están optimizadas por el motor de almacenamiento. El motor relacional determina el método de acceso más eficaz (como un examen de tabla, un examen de índice o una lectura con clave). Los métodos de acceso y los componentes del administrador de búfer del motor de almacenamiento determinan el patrón general de lecturas que se van a realizar y optimizan las lecturas necesarias para implementar el método de acceso. El subproceso que ejecuta el lote programa las lecturas.
Lectura anticipada
El Motor de base de datos admite un mecanismo de optimización del rendimiento denominado lectura anticipada. La lectura anticipada anticipa los datos y las páginas de índice necesarias para cumplir un plan de ejecución de consultas y lleva las páginas a la memoria caché del búfer antes de que la consulta las use. Este proceso permite que el cálculo y la E/S se superpongan, aprovechando al máximo la CPU y el disco.
El mecanismo de lectura anticipada permite al motor de base de datos leer hasta 64 páginas contiguas (512 KB) desde un archivo. Esta lectura se realiza como única lectura por dispersión y recopilación en el número adecuado de búferes (probablemente no contiguos) de la caché del búfer. Si alguna de las páginas del intervalo ya está presente en la caché del búfer, la página correspondiente de la lectura se descarta cuando se complete la lectura. El intervalo de páginas también puede "recortarse" desde cualquier extremo si las páginas correspondientes ya están presentes en la memoria caché.
Hay dos tipos de lectura anticipada: uno para las páginas de datos y otro para las páginas de índice.
Leer páginas de datos
Los exámenes de tabla utilizados por el motor de base de datos para leer páginas de datos son eficaces. Las páginas del Mapa de asignación de índices (IAM) de una base de datos de SQL Server enumeran las extensiones que utiliza una tabla o un índice. El motor de almacenamiento puede leer la IAM para generar una lista ordenada de las direcciones de disco que deben leerse. Esto permite al motor de almacenamiento optimizar sus operaciones de E/S como lecturas secuenciales de gran tamaño que se realizan en un orden basado en su ubicación en el disco. Para obtener más información sobre las páginas de IAM, consulte Administración del espacio usado por objetos.
Leer páginas de índice
El motor de almacenamiento lee las páginas de índice en serie, ordenadas por clave. Por ejemplo, esta ilustración muestra una representación simplificada de un conjunto de páginas hoja que contienen un conjunto de claves y el nodo del índice intermedio que asigna las páginas hoja. Para obtener más información sobre la estructura de las páginas de un índice, vea Índices agrupados y no agrupados.
El motor de almacenamiento utiliza la información de la página de índice intermedio que se encuentra por encima del nivel hoja para programar las lecturas anticipadas en serie de las páginas que contienen las claves. Si se realiza una solicitud para todas las claves de ABC
a DEF
, el motor de almacenamiento lee primero la página de índice encima de la página de hoja. Sin embargo, no solo lee cada página de datos en secuencia de la página 504 a la página 556 (la última página con claves en el intervalo especificado). En cambio, el motor de almacenamiento recorre la página de índice intermedio y genera una lista con las páginas hoja que deben leerse. A continuación, el motor de almacenamiento programa todas las lecturas en orden de clave. El motor de almacenamiento reconoce también que las páginas 504/505 y las páginas 527/528 son contiguas, y realiza una única lectura por dispersión para recuperar las páginas adyacentes en una sola operación. Cuando hay muchas páginas que tienen que recuperarse con una operación en serie, el motor de almacenamiento programa un bloque de lecturas cada vez. Cuando se completa un subconjunto de estas lecturas, el motor de almacenamiento programa un número igual de lecturas nuevas hasta que se programan todas las lecturas necesarias.
El motor de almacenamiento usa la captura previa para acelerar las búsquedas de tablas base de índices no agrupados. Las filas hoja de un índice no clúster contienen punteros a las filas de datos que incluyen cada valor de clave específico. Mientras el motor de almacenamiento examina las páginas hoja del índice no clúster, también comienza a programar lecturas asincrónicas de las filas de datos cuyos punteros ya se recuperaron. Esto permite al motor de almacenamiento recuperar filas de datos de la tabla subyacente antes de completar el examen del índice no clúster. La captura previa se usa independientemente de si la tabla dispone de un índice clúster o no. SQL Server Enterprise Edition usa más captura previa que otras ediciones de SQL Server, lo que permite leer más páginas. El nivel de captura previa no se puede configurar en ninguna edición. Para obtener más información sobre los índices no agrupados, consulte Índices agrupados y no clúster.
Escaneo avanzado
En la edición SQL Server Enterprise, la característica de examen avanzado permite que varias tareas compartan exámenes completos de tablas. Si el plan de ejecución de una instrucción Transact-SQL requiere un recorrido de las páginas de datos de una tabla y el Motor de base de datos detecta que la tabla ya se recorre en otro plan de ejecución, el Motor de base de datos combina el segundo recorrido con el primero en la ubicación actual del segundo. El Motor de base de datos lee cada página una vez y pasa las filas de cada página a ambos planes de ejecución. Esto continúa hasta que se llega al final de la tabla.
En ese momento, el primer plan de ejecución tiene los resultados completos de un escaneo. Sin embargo, el segundo plan de ejecución todavía debe recuperar las páginas de datos que se leyeron antes de unirse al escaneo en progreso. A continuación, el recorrido del segundo plan de ejecución vuelve a la primera página de datos de la tabla y recorre hasta donde se combinó con el primer recorrido. Se puede combinar cualquier número de escaneos de esta forma. El motor de base de datos realiza un bucle en las páginas de datos hasta que completa todos los exámenes. Este mecanismo también se denomina "recorrido cíclico" y demuestra por qué no se puede garantizar el orden de los resultados devueltos de una instrucción SELECT
sin una cláusula ORDER BY
.
Por ejemplo, supongamos que dispone de una tabla con 500.000 páginas. UserA
ejecuta una instrucción Transact-SQL que requiere un examen de la tabla. Cuando ese examen ha procesado 100 000 páginas, UserB
ejecuta otra instrucción Transact-SQL que examina la misma tabla. Motor de base de datos programa un conjunto de solicitudes de lectura de las páginas siguientes a la 100.001 y devuelve las filas de cada página a ambos recorridos. Cuando el examen alcanza la página 200.000, UserC
ejecuta otra instrucción Transact-SQL que examina la misma tabla. Comenzando con la página 200.001, el Motor de base de datos devuelve las filas de cada página que lee a los tres recorridos. Después de leer la fila 500.000, el escaneo de UserA
está completo y los escaneos de UserB
y UserC
vuelven al principio y empiezan a leer las páginas comenzando por la página 1. Cuando el Motor de base de datos llega a la página 100.000, se completa el recorrido del UserB
. El recorrido del UserC
se mantiene en solitario hasta que llega a la página 200.000. En este momento, se han completado todos los escaneos.
Sin el recorrido avanzado, cada usuario tendría que competir por espacio en búfer y se produciría una contención en el brazo del disco. Entonces se leerían las mismas páginas una vez por cada usuario, en lugar de leerlas una vez y compartirlas entre varios usuarios, lo que ralentizaría el rendimiento y consumiría muchos recursos.