sql >> Base de Datos >  >> RDS >> Sqlserver

Comparar planes de ejecución en SQL Server

El administrador de la base de datos siempre se esfuerza por ajustar el rendimiento de las consultas de SQL Server. El primer paso para ajustar el rendimiento de las consultas es analizar el plan de ejecución de una consulta. Bajo algunas condiciones, SQL Server Query Optimizer puede crear diferentes planes de ejecución. En este punto, me gustaría agregar algunas notas sobre SQL Server Query Optimizer. SQL Server Query Optimizer es un optimizador basado en costos que analiza los planes de ejecución y decide el plan de ejecución óptimo para una consulta. La palabra clave importante para SQL Server Query Optimizer es un plan de ejecución óptimo que no es necesariamente el mejor plan de ejecución. Por eso, si SQL Server Query Optimizer intenta encontrar el mejor plan de ejecución para cada consulta, toma más tiempo y daña el rendimiento del motor de SQL Server. En SQL Server 2016, Microsoft agregó una nueva capacidad a SQL Server Management Studio, llamada Compare Showplan. Esta característica nos permite comparar dos planes de ejecución diferentes. Al mismo tiempo, podemos usar esta opción sin conexión, lo que significa que no necesitamos conectar la instancia de SQL Server. Imagine que escribe una consulta y esta consulta funciona bien en el entorno de PRUEBA, pero en PROD (entorno de producción), funciona muy mal. Para manejar este problema, necesitamos comparar los planes de ejecución. Antes de esta función, solíamos abrir dos SQL Server Management Studios y llevar los planes de ejecución uno al lado del otro, pero este método era muy inconveniente.

¿Cómo comparar dos planes de ejecución?

En esta demostración, usaremos la base de datos AdventureWorks y compararemos dos planes de ejecución que tienen una versión del modelo de estimación de cardinalidad diferente y detectaremos esta diferencia con Compare Showplan.

Primero, abriremos una nueva ventana de consulta en SQL Server Management Studio y haremos clic en Incluir plan de ejecución real y luego ejecute la siguiente consulta.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
		INNER JOIN [Person].[Person] p
		ON p.[BusinessEntityID] = sp.[BusinessEntityID]

En este paso, guardaremos nuestro primer plan de ejecución. Haga clic derecho en cualquier parte del plan de ejecución y haga clic en Guardar plan de ejecución como y guarde el plan de ejecución como ExecutionPlan_CE140.sqlplan.

Ahora abriremos una nueva pestaña de consulta en SQL Server Management Studio y ejecutaremos la siguiente consulta. En esta consulta, agregaremos la sugerencia de consulta FORCE_LEGACY_CARDINALITY_ESTIMATION al final de la consulta, lo que obliga a usar una versión anterior del modelo de estimación de cardinalidad.
La tarea de estimación de cardinalidad es predecir cuántas filas devolverá nuestra consulta.

SELECT 
        soh.[SalesPersonID]
        ,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
        ,e.[JobTitle]
        ,st.[Name] AS [SalesTerritory]
        ,soh.[SubTotal]
        ,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear] 
    FROM [Sales].[SalesPerson] sp 
        INNER JOIN [Sales].[SalesOrderHeader] soh 
        ON sp.[BusinessEntityID] = soh.[SalesPersonID]
        INNER JOIN [Sales].[SalesTerritory] st 
        ON sp.[TerritoryID] = st.[TerritoryID] 
        INNER JOIN [HumanResources].[Employee] e 
        ON soh.[SalesPersonID] = e.[BusinessEntityID] 
INNER JOIN [Person].[Person] p
	ON p.[BusinessEntityID] = sp.[BusinessEntityID]
	OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Haremos clic en Comparar Showplan y seleccione el plan de ejecución anterior que se guardó como ExecutionPlan_CE140.sqlplan.

La siguiente imagen ilustra la primera pantalla del plan de comparación de ejecución de SQL Server y las áreas resaltadas en color rosa definen operaciones similares.

Si hacemos clic en cualquier operador en la pantalla del plan de ejecución inferior o superior, SQL Server Management Studio resalta otros operadores similares. En el lado derecho del panel, puede encontrar propiedades y detalles de comparación de propiedades.

En este paso, cambiaremos las opciones de ShowPlan Analysis y resaltaremos el operador que no coincide. En la parte inferior de la pantalla, podemos ver el Showplan Analysis panel. Si desactivamos Resaltar operaciones similares y seleccione Resaltar operadores que no coincidan con segmentos similares, SQL Server Management Studio destaca un operador sin igual. Después de eso, haga clic en Seleccionar operadores en el plan de ejecución de abajo y arriba en el panel. SQL Server Management Studio compara las propiedades de los operadores seleccionados y pone signos de desigualdad a los valores no idénticos.

Si analizamos esta pantalla con más detalle, lo primero es la Versión del modelo de estimación de cardinalidad diferencia. La primera versión de consulta es 70 y la segunda es 140. Esta diferencia afecta al Número estimado de filas . La razón principal que causa el diferente Número estimado de filas es una versión diferente de la estimación de cardinalidad. Por lo tanto, la versión de estimación de cardinalidad afecta directamente a las métricas estimadas de la consulta. Para esta comparación de consultas, podemos concluir que la consulta cuya versión de estimación de cardinalidad es 140 funciona mejor porque el número estimado de filas está cerca del Número real de filas . Este caso se puede aclarar en la siguiente tabla.

[identificación de la tabla=50 /]

Si queremos ver los planes de ejecución uno al lado del otro en la misma pantalla, podemos hacer clic en Alternar orientación del divisor .

Ahora haremos otra demostración. Examinaremos la consulta a continuación y compararemos los planes de ejecución antes y después de la creación del índice.
Cuando observamos el plan de ejecución de la consulta a continuación, se recomienda crear un índice no agrupado.

SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

Aplicaremos el índice recomendado y volveremos a ejecutar la misma consulta.

CREATE NONCLUSTERED INDEX Index_NC
ON [Sales].[SalesOrderDetail] ([SalesOrderDetailID])
GO
SELECT [CarrierTrackingNumber] 
FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12

En este último paso, compararemos los planes de ejecución.

En la imagen superior podemos obtener varios datos sobre los planes de ejecución. Pero la principal diferencia es la Operación Lógica campo. Uno de ellos es Búsqueda de índice y otro es Index Scan y esta operación de diferenciación conduce a valores métricos estimados y reales diferentes. Por último, el operador Index Seek se desempeña mejor que el operador Index Scan.

Conclusiones

Como mencionamos en el artículo, la función Comparar plan de presentación ofrece algunos beneficios al desarrollador o administrador de la base de datos. Algunos de estos se pueden contar como:

  • Fácil de comparar la diferencia de dos planes de ejecución.
  • Fácil de detectar problemas de rendimiento de consultas en diferentes versiones de SQL Server.
  • Fácil de detectar problemas de rendimiento de consultas en diferentes entornos.
  • Simplemente aclara los cambios del plan de ejecución antes y después de la creación del índice.

Referencias

  • Estimación de cardinalidad (SQL Server)
  • Guía de arquitectura de procesamiento de consultas