UNIVERSIDAD MARIANO GÁLVEZ

FACULTAD DE INGENIERÍA
INGENIERO MIGUEL LEMUS
BASE DE DATOS II

INVESTIGACIÓN

KARIN NATHALÍ ARGUETA CHÁVEZ 3090-13-11602

SEPTIMO SEMESTRE DE INGENIERIA

MAZATENANGO, 8 DE ABRIL DEL 2022.

 OPTIMIZACIÓN DE CONSULTAS
Se refiere a mejorar los tiempos de respuesta en un sistema de gestión de
bases de datos relacional, pues la optimización es el proceso de modificar un
sistema para mejorar su eficiencia o también el uso de los recursos disponibles.

TIPS DE OPTIMIZACIÓN

El primer tip de optimización de una base de datos SQL, es invertir el tiempo

en aprender SQL a detalle. En muchas ocasiones, un mismo resultado puede
obtenerse con distintos tipos de consultas, en ocasiones, 3 consultas se
pueden ejecutar en una sola.

Se le denomina optimización de consultas porque trata de disminuir la

cantidad de consultas pero que siga ejecutando y solicitando todos los datos
relevantes.
Aquí podemos observar algunos ejemplos.
OR en la cláusula Join Predicate/WHERE en varias columnas

El SQL Server nos muestra que puede filtrar eficientemente un conjunto de

datos utilizando índices a través y por medio de la cláusula WHERE o cualquier
combinación de filtros separados por un operador AND. Al ser exclusivas, todas
estas operaciones que toman datos y los dividen en partes progresivamente
más pequeñas, hasta que solo queda nuestro conjunto de resultados.

OR es una historia diferente. Debido a que es inclusivo, SQL Server no puede

procesarlo en una sola operación. Entonces podemos indicar que, cada
componente del OR debe evaluarse de forma independiente. Cuando se
completa esta operación costosa, los resultados se pueden concatenar y
devolver a la situación de forma muy ordenada normalmente.
 El peor caso de escenario en el que OR funciona de manera ineficiente es
cuando hay varias columnas o tablas involucradas. No solo necesitamos
evaluar cada componente de la cláusula OR, sino que debemos seguir esa ruta
a través de los otros filtros y tablas dentro de la consulta. Pese a que podría
darse el caso de que incluso solo intervienen unas pocas tablas o columnas, se
tiene que el rendimiento puede ser increíblemente malo.

Aquí hay un ejemplo muy simple de cómo un OR puede causar que el

rendimiento empeore mucho más de lo que imaginas:

1SELECT DISTINCT
2 PRODUCT.ProductID,
3 PRODUCT.Name
4FROM Production.Product PRODUCT
5INNER JOIN Sales.SalesOrderDetail DETAIL
6ON PRODUCT.ProductID = DETAIL.ProductID
7OR PRODUCT.rowguid = DETAIL.rowguid;

La consulta es bastante simple: 2 tablas y una combinación que verifica

tanto ProductID como rowguid. Incluso pese a que, si ninguna de estas
columnas estuviera indexada, nuestra expectativa sería un escaneo de tabla
en Producto y un escaneo de tabla en SalesOrderDetail. Caro, pero por lo
menos es algo que podemos comprender. Aquí está el rendimiento resultante
de esta consulta:
 Nosotros efectuamos el escaneo de ambas tablas, pero procesar el OR requirió
una cantidad absurda de recursos del sistema. ¡1,2 millones de lecturas se
hicieron en este esfuerzo! Teniendo en cuenta que el Producto contiene solo
504 filas y SalesOrderDetail contiene 121317 filas, leemos muchos más datos
que el contenido completo de cada una de estas tablas. Adicionalmente se
tiene que, Además, la consulta tardó aproximadamente 2 segundos en
ejecutarse en un escritorio con SSD relativamente rápido.

La conclusión de esta demostración aterradora es que SQL Server no puede

procesar fácilmente una condición OR en varias columnas. Por esta razón es
que la mejor manera de lidiar con un OR es eliminarlo (si es posible) o dividirlo
en consultas más pequeñas. Ya que por el contrario interrumpir una consulta
corta y simple en una consulta más larga y prolongada puede no parecer
elegante, pero al menos cuando se trata de problemas OR, a menudo es la
mejor opción:

1 SELECT
2 PRODUCT.ProductID,
3 PRODUCT.Name
4 FROM Production.Product PRODUCT
5 INNER JOIN Sales.SalesOrderDetail DETAIL
6 ON PRODUCT.ProductID = DETAIL.ProductID
7 UNION
8 SELECT
9 PRODUCT.ProductID,
10 PRODUCT.Name
11FROM Production.Product PRODUCT
12INNER JOIN Sales.SalesOrderDetail DETAIL
13ON PRODUCT.rowguid = DETAIL.rowguid

En esta reescritura de los procesos, nos tomamos cada componente del OR y

lo convertimos en su propia instrucción SELECT. UNION la que por sí misma
concatena el conjunto de resultados y elimina los duplicados. Aquí está el
rendimiento resultante:
En este caso, el plan de ejecución se volvió significativamente más complejo,
debido a que ahora estamos consultando cada tabla dos veces, en lugar de
una, pero ya no necesitábamos jugar a ponerle la cola al burro de forma
aleatoria con los conjuntos de resultados como lo hicimos antes. Las lecturas
se redujeron significativamente de 1,2 millones a 750, y logrando que la
consulta se ejecute en menos de un segundo, en lugar de en 2 segundos.

Tenga en cuenta que todavía hay una gran cantidad de escaneos de índice en
el plan de ejecución, pero a pesar de la necesidad de escanear tablas cuatro
veces para satisfacer nuestra consulta, el rendimiento es mucho mejor que
antes.

Es importante tener cuidado al escribir consultas con una cláusula OR. Por ello,
es crítico que pruebe y verifique que el rendimiento sea adecuado y que no
esté introduciendo accidentalmente una bomba de tiempo de rendimiento
similar a lo que observamos anteriormente. Si está revisando una aplicación
de bajo rendimiento, la misma que se ejecuta en un OR en diferentes columnas
o tablas, usted deberá concentrarse en eso como una posible causa de los
 problemas. Este es un patrón de consulta fácil de identificar que a menudo
conduce a un bajo rendimiento.

Búsquedas de cadenas comodín

La búsqueda de las cadenas de manera eficiente puede ser un gran desafío, y

además de que hay muchas más formas de procesar cadenas de manera
ineficiente que eficiente. Para las columnas de cadenas buscadas con
frecuencia, debemos asegurarnos de que:

• Los índices están presentes en las columnas buscadas

• Se pueden usar esos índices
• Si no, ¿podemos usar índices de texto completo?
• Si no, ¿podemos usar hashes, n-grams o alguna otra solución?

Debe ser muy importante el considerar que, sin el uso de características

adicionales o consideraciones de diseño, el SQL Server no es bueno y eficiente
en la búsqueda de cadenas difusas. Es decir, si quiero detectar la presencia de
una cadena en cualquier posición dentro de una columna, obtener esos datos
será ineficiente:

1SELECT
2 Person.BusinessEntityID,
3 Person.FirstName,
4 Person.LastName,
5 Person.MiddleName
6FROM Person.Person
7WHERE Person.LastName LIKE '%For%';

En esta búsqueda de las cadenas específicas, estamos

verificando Apellido para cualquier ocurrencia de “For” en cualquier posición
dentro de la cadena. Recuerde que lo importante es que cuando se coloca un
“%” al comienzo de una cadena, estamos haciendo imposible el uso de
cualquier índice ascendente. De manera similar, cuando un “%” está al final de
una cadena, también es imposible usar un índice descendente. La consulta
anterior dará como resultado el siguiente rendimiento:

Como se esperaba, la consulta da como resultado efectuar un escaneo

en Person.Person. La única forma de saber si existe una subcadena dentro de
una columna de texto es desplazarse a través de cada carácter en cada fila,
buscando ocurrencias de esa cadena. En una tabla pequeña, esto puede ser
aceptable, pero de contraparte el efectuar una comparación con cualquier
conjunto de datos de gran tamaño, será lento laborioso y doloroso esperar.

Hay una variedad de formas de atacar esta situación, que incluyen:

• Reevaluar la aplicación. ¿Realmente necesitamos hacer una búsqueda

con comodines de esta manera? ¿Los usuarios realmente quieren
buscar en todas las partes de esta columna una cadena determinada? Si
no, ¡elimine esta capacidad y el problema desaparece! Si no hay
problema de que preocuparse.
• ¿Podemos aplicar otros filtros a la consulta para reducir el tamaño de
los datos antes de analizar la comparación de cadenas? Si podemos
filtrar por fecha, hora, estado o algún otro tipo de criterio comúnmente
utilizado, tal vez podríamos reducir los datos que necesitamos escanear
a una cantidad lo suficientemente pequeña como para que nuestra
consulta tenga un rendimiento aceptable.
• ¿Podemos hacer una búsqueda de cadena principal, en lugar de una
búsqueda con comodines? ¿Se puede cambiar “% For%” a “For%”?
 • ¿La indexación de texto completo es una opción disponible? ¿Podemos
implementarlo y usarlo?
• ¿Podemos implementar una solución hash o n-gram de consulta?

Las primeras 3 opciones anteriores son percibidas como tantas

consideraciones de diseño/arquitectura como soluciones de optimización. Por
ello la pregunta es: ¿Qué más podemos suponer, cambiar o comprender
acerca de esta consulta para ajustarla para que funcione bien? Todos estos
cuestionamientos requieren cierto nivel de conocimiento de la aplicación o la
capacidad de cambiar los datos devueltos por una consulta. Puede que estas
no sean opciones disponibles para nosotros, en razón de esto es crítico y es
importante involucrar a todas las partes que estén inmersos en el mismo tema
y enfoque con respecto a la búsqueda de cadenas. Por ejemplo, en el caso de
que una tabla tiene mil millones de filas y los usuarios desean buscar con
frecuencia en una columna NVARCHAR (MAX) y la aparición de cadenas en
cualquier posición, se tiene entonces que es necesario que se lleve a cabo una
discusión seria sobre por qué alguien querría hacer esto y qué alternativas
están disponibles. Si esa funcionalidad es realmente importante, entonces la
empresa necesitará comprometer recursos adicionales para soportar la
costosa búsqueda de cadenas, o aceptar una gran cantidad de retraso,
lentitud, latencia y consumo de recursos en el proceso.

Es muy importante mencionar que la indexación de texto completo es una

característica en SQL Server que puede generar índices que permitirán la
búsqueda de cadenas flexibles en columnas de texto. Es necesario recordar
que esto incluye búsquedas con comodines, pero también búsquedas
lingüísticas de contexto que utilizan las reglas de un idioma determinado para
tomar decisiones inteligentes sobre si una palabra o frase son lo
suficientemente similares y adecuadas al contenido de una columna como
para considerarse una adecuada coincidencia. Si bien es flexible, es importante
mencionar que el texto completo es una característica adicional que debe
instalarse, configurarse y mantenerse. Para algunas aplicaciones que están
muy centradas en cadenas, esta de manera muy crítica ¡puede ser la solución
perfecta! Se proporciona un enlace al final de este artículo con más detalles
sobre esta característica, lo que puede hacer con ella, cómo instalarlo y
configurarlo.
 Deberemos considerar que una última opción disponible para nosotros puede
ser una gran solución para columnas de cadenas más cortas. Los N-Grams son
segmentos de cadena que se pueden almacenar por separado de los datos que
estamos buscando y pueden proporcionar la capacidad de buscar subcadenas
sin la necesidad de escanear una tabla grande. Antes de discutir este tema, es
importante comprender completamente las reglas de búsqueda que utiliza
una aplicación. Por ejemplo:

• ¿Se permite un número mínimo o máximo de caracteres en una

búsqueda?
• ¿Se permiten búsquedas vacías (un escaneo de tabla)?
• ¿Se permiten múltiples palabras/frases?
• ¿Necesitamos almacenar subcadenas al comienzo de una cadena? Estos
se pueden recopilar con una búsqueda de índice si es necesario

Hay que considerar que una vez que se evalúan estas consideraciones,
podemos tomar una columna de cadena y dividirla en segmentos de cadena.
Por ejemplo, en el caso de que debemos considerar un sistema de búsqueda
donde hay una longitud mínima de búsqueda de 3 caracteres y la palabra
almacenada “Dinosaurio”. Es aquí donde están las subcadenas de Dinosaurio
que tienen 3 caracteres de longitud o más (ignorando el inicio de la cadena,
que se puede reunir por separado y rápidamente con una búsqueda de índice
en esta columna):
ino, inos, inosa, inosau, inosaur, nos, nosa, nosau, nosaur, osa, osau, osaur,
sau, saur, aur.

Si tuviéramos que crear una tabla separada que almacenara cada una de estas
subcadenas (también conocidas como n-gramos), podemos vincular esos n-
gramos a la fila de nuestra gran tabla que tiene la palabra dinosaurio. Por esta
razón, en lugar de escanear una tabla grande para obtener resultados,
podemos hacer una búsqueda de igualdad contra la tabla de n-grams. Por
ejemplo, si tuve que elaborar una búsqueda comodín para “dino”, mi
búsqueda se puede redirigir a una búsqueda que se vería así:

1SELECT
2 n_gram_table.my_big_table_id_column
3FROM dbo.n_gram_table
4WHERE n_gram_table.n_gram_data = 'Dino';

Suponiendo que n_gram_data está indexado, deberemos devolver

rápidamente todos los IDs de nuestra tabla grande que tenga la palabra Dino
en cualquier lugar. La tabla de n-grams solo requiere 2 columnas, y podemos
vincular el tamaño de la cadena de n-grams utilizando nuestras reglas de
aplicación definidas anteriormente. Incluso si se tiene el caso de que, si esta
tabla se hace grande, es probable que proporcione capacidades de búsqueda
muy rápidas.

Hay que recordar que el costo es importante de este enfoque es el

mantenimiento. Por esta razón, necesitamos actualizar la tabla de n-grams
cada vez que se inserta, se elimina o se actualizan los datos de la cadena.
Además, el número de n-grams por fila aumentará rápidamente a medida que
aumenta el tamaño de la columna. Esta situación nos dará como resultado, un
enfoque excelente para cadenas más cortas, como nombres, códigos postales
o números de teléfono. Pese a que es una solución muy costosa para cadenas
más largas, como texto de correo electrónico, descripciones y otras columnas
de formato libre o longitud máxima.

Para recapitular rápidamente: hay que tomar en consideración que la

búsqueda de cadenas comodín es inherentemente costosa. Nuestras mejores
armas contra ella se basan en las eficientes reglas de diseño y arquitectura que
nos permiten eliminar el “%” principal o limitar la forma en que buscamos de
manera que permitan la implementación de otros filtros o soluciones. Por esta
consideración, al final de este artículo se proporcionó un enlace con más
información y algunas demostraciones de cómo generar y usar datos de n-
grams. Si bien es una implementación más complicada, es otra arma muy
importante en nuestro arsenal cuando otras opciones nos han fallado.

Operaciones de escritura grandes

Es importante mencionar que Después de una discusión de por qué la iteración

puede causar un rendimiento deficiente, es ahora que vamos a explorar un
escenario en el que contrariamente se tiene la situación en el que la iteración
MEJORA el rendimiento. Un componente de optimización aún no discutido
aquí es la contención. Debemos recordar de que cuando realizamos cualquier
operación contra los datos, se puede observar que se tienen bloqueos contra
cierta cantidad de datos para garantizar que los resultados sean consistentes
y no interfieran con otras consultas que otros además de nosotros están
ejecutando en contraposición de los mismos datos.

El cierre y el bloqueo de datos en algunas circunstancias puede ser el resultado

de tener cosas buenas, ya que protegen los datos de la corrupción y nos
protegen de los malos resultados. Sin embargo, cuando la contienda continúa
por un largo tiempo, las consultas importantes pueden verse obligadas a
esperar, lo que resulta en usuarios descontentos y las quejas de retaso y
lentitud que genera latencia resultante.

Las operaciones de escritura grandes son el elemento secundario de la disputa,

ya que a menudo bloquean una tabla completa durante el tiempo que lleva
actualizar los datos, verificar restricciones, actualizar índices y desencadenar
procesos (si los hay). Se deberá responder a las siguientes inquietudes ¿Qué
tan grande es grande? No hay una regla estricta aquí. En una tabla sin
desencadenadores o claves externas, grande podría ser 50,000, 100,000 o
1,000,000 de filas. En una tabla con muchas restricciones y desencadenadores,
grande podría ser 2,000. La única forma de confirmar que se trata de un
problema es tomar en la realidad el probarlo, observarlo y responder en
consecuencia.

Además de la contención, las grandes operaciones de escritura generarán un

gran crecimiento del archivo de registro. Recuerde que siempre que escriba
volúmenes de datos inusualmente grandes, usted deberá vigilar el registro de
transacciones y verificar que no corre el riesgo de llenarlo, o peor aún, de llenar
su ubicación de almacenamiento físico.

Debemos considerar que se tiene que tener en cuenta que muchas

operaciones de escritura grandes serán el resultado de nuestro propio trabajo:
las versiones de software, los procesos de carga del almacén de datos, los
procesos ETL y otras operaciones similares pueden necesitar escribir una gran
cantidad de datos, incluso si se realiza con poca frecuencia. Debemos recordar
que la prioridad de escribir documentos largos depende de nosotros el
identificar el nivel de contención permitido para realizar nuestras tablas antes
de ejecutar estos procesos. Si estamos cargando una tabla grande durante una
ventana de mantenimiento cuando nadie más la está usando, entonces somos
libres de implementarla usando cualquier estrategia que deseemos. Por otra
parte, si se da la situación en la que estamos escribiendo grandes cantidades
de datos en un sitio de producción ocupado, entonces deberemos reducir las
filas modificadas por operación lo que sería una buena protección contra la
contención.

Las operaciones comunes que pueden dar lugar a grandes escrituras son:

• Agregar una nueva columna a una tabla y rellenarla en toda la tabla

• Actualización de una columna en una tabla completa
• Cambiar el tipo de datos de una columna. Vea el enlace al final del
artículo para obtener más información al respecto
• Importar un gran volumen de datos nuevos
• Archivar o eliminar un gran volumen de datos antiguos

Esto puede no ser a menudo un problema de rendimiento, pero es importante

comprender los efectos de operaciones de escritura muy grandes ya que es
factible el poder evitar eventos de mantenimiento importantes o lanzamientos
que se descarrilan inesperadamente.

Índices faltantes

Debemos considerar que SQL Server, a través de la GUI de Management

Studio, el XML del plan de ejecución o los DMV de índice que faltan, permitirá
que recibamos la información cuando faltan índices que podrían ayudar a que
una consulta funcione mejor:

Esta advertencia es útil porque nos permite saber que a diferencia de otras
circunstancias que existe una solución potencialmente más fácil para mejorar
el rendimiento de las consultas. Por otra parte también tiene un lado obscuro
ya que también es engañoso porque un índice adicional puede no ser la mejor
manera de resolver un problema de atraso y de latencia. El texto verde nos
proporciona todos los detalles de un nuevo índice, pero tenemos que hacer un
poco de trabajo antes de considerar tomar el consejo de SQL Server:
 • ¿Existen índices existentes que sean similares a este que puedan
modificarse para cubrir este caso de estudio?
• ¿Necesitamos todas las columnas de inclusión? ¿Sería suficiente un
índice en las columnas de clasificación?
• ¿Qué tan alto es el impacto del índice? ¿Mejorará una consulta en un 98
%, o solo en un 5 %?
• ¿Este índice ya existe, pero por alguna razón el optimizador de consultas
no lo elige?

A menudo, los índices sugeridos son excesivos. Por ejemplo, aquí está la
instrucción de creación de índice para el plan parcial que se muestra arriba:

1CREATE NONCLUSTERED INDEX <Name of Missing Index, sysname,>

2ON Sales.SalesOrderHeader (Status,SalesPersonID)
3INCLUDE (SalesOrderID,SubTotal)

En este caso, ya hay un índice en SalesPersonID. El estado es una columna en

la que la tabla contiene principalmente un valor, por lo que significa que, como
columna de clasificación, no nos proporcionaría mucho valor. El impacto del
19% no es terriblemente impresionante. En última instancia, deberíamos
preguntarnos si la consulta es lo suficientemente importante como para
garantizar esta mejora. Por otra parte, si se ejecuta un millón de veces al día,
entonces quizás todo este trabajo para una mejora del 20% valga la pena.

Considere otra recomendación de índice alternativa:

 Aquí, el índice que falta es:

1CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]

2ON [Person].[Person] ([FirstName])
3INCLUDE ([BusinessEntityID],[Title])

Es importante observar que, por esta vez, el índice sugerido proporcionaría

una mejora del 93% y manejaría una columna no indexada (Nombre). Si la
situación existente es que esta es una consulta que se ejecuta con frecuencia,
entonces agregar este índice probablemente sería un movimiento inteligente.
¿Agregamos BusinessEntityID y Title como columnas INCLUDE? Esta es una
pregunta mucho más subjetiva y debemos decidir si la consulta es lo
suficientemente importante como para querer asegurarnos de que nunca haya
una búsqueda clave para extraer esas columnas adicionales del índice
agrupado. Recuerde que la presente interrogante de esta pregunta es un eco
de “¿Cómo sabemos cuándo el rendimiento de una consulta es óptimo?”.
Deberemos verificar que, si el índice de no cobertura es lo suficientemente
bueno, detenerse allí sería la decisión correcta, ya que ahorraría los recursos
informáticos necesarios para almacenar las columnas adicionales. Pero de
contraparte si el rendimiento aún no es lo suficientemente bueno, entonces el
siguiente paso lógico sería agregar las columnas INCLUDE.
Siempre que recordemos que los índices requieren mantenimiento y
ralentizan las operaciones de escritura, podemos abordar la indexación desde
una perspectiva pragmática y asegurarnos de no cometer ninguno de estos
errores:

Indexación excesiva de una tabla

Resulta bastante lógico que cuando una tabla tiene demasiados índices, las
operaciones de escritura se vuelven más lentas ya que cada ACTUALIZACIÓN,
BORRADO e INSERCIÓN que toca una columna indexada debe actualizar todos
los índices en ella. Además, esos índices ocupan espacio en el
almacenamiento, así como en las copias de seguridad de la base de datos. El
término de “Demasiados” es vago, pero enfatiza que, en última instancia, el
rendimiento de la aplicación es la clave para determinar si las cosas son
óptimas o no.

Subindexar una tabla

Una tabla subindexada no sirve para efectuar las consultas de lectura de

manera efectiva. Por tanto, de manera ideal, las consultas más comunes
ejecutadas en una tabla deberían beneficiarse de los índices. Las consultas
menos frecuentes se evalúan caso por caso y se indexan cuando son
beneficiosas. Recordemos que cuando se soluciona un problema de
rendimiento en tablas que tienen pocos o ningún índice no agrupado,
entonces es probable que el problema sea de baja indexación. Es importante
mencionar que, en estos casos, ¡puede sentirse facultado para agregar índices
para mejorar el rendimiento según sea necesario!

PLANES DE EJECUCIÓN

En Planes de ejecución de consultas SQL Server – Básicos, describimos los

planes de ejecución de consultas en SQL Server y por qué son importantes para
el análisis de desempeño. En este artículo, nos enfocaremos en los métodos
para abrir los planes, tanto los verdaderos como los estimados.
Si usted mira al elemento Query en el menú de SQL Server Management
Studio, usted verá dos opciones relacionadas a los planes de consultas –
Display Estimated Execution plan e Include Actual Execution plan.

Un plan de ejecución estimado es un plan de consultas SQL Server que es

generado sin realmente correr la consulta (o procedimiento almacenado) para
el cual el plan es creado. Está basado en una estimación de comportamiento
esperado. Es útil para analizar cómo se comportaría una consulta sin
realmente correrla. Esto es muy útil para propósitos de pruebas en ambientes
donde el desempeño no debería ser afectado al correr el código real (por
ejemplo, correr una sentencia SELECT con uniones complejas con tablas
enormes), o cuando correr el código no es posible debido a los cambios en los
datos que hace (por ejemplo, ejecutar un UPDATE). Su desventaja es que
puede ser poco preciso en algunos escenarios.

Un plan de ejecución real es el plan de consultas SQL Server que es generado

después de que una consulta fuera ejecutada. Es más confiable, y está basado
en la ejecución real, no estimados. También provee más información y
estadísticas, por lo que es mucho más útil al resolver problemas.

Hay muchos métodos disponibles para abrir un plan de consultas en SQL

Server.

Include Actual Execution Plan

La opción Include Actual Execution Plan está disponible en el menú de SQL

Server Management Studio.

1. Seleccione Query en el menú de SQL Server Management Studio

2. Seleccione la opción Include Actual Execution Plan, o presione Ctrl +
M en el teclado.

Ahora, cada vez que usted ejecute una consulta o procedimiento almacenado
ad hoc, una pestaña adicional aparecerá en el panel de resultados, al lado de
las pestañas Results y Messages.
1SELECT *
2 FROM person.PersonPhone
3 WHERE PhoneNumber LIKE '%697%'

Si múltiples consultas SQL son ejecutadas, sus planes serán listados en la

misma pestaña, una debajo de la otra. Cada elemento en el plan de consultas
muestra una sugerencia con información adicional.

Los planes de ejecución SQL Server pueden ser grabados como XML o archivos
sqlplan para análisis posterior. Para abrir un archivo sqlplan, haga doble clic en
el archivo en el explorador de archivos y será automáticamente abierto en SQL
Server Management Studio.

Los pasos son similares para usar la opción Display Estimated Execution Plan,
excepto que la consulta no tiene que ser ejecutada.

Los planes de consultas SQL Server también pueden ser mostrados en el Editor
de Consultas usando alguna de las siguientes opciones:
SHOWPLAN_XML

La opción SHOWPLAN_XML tiene que ser establecida usando T-SQL y muestra

el plan de ejecución estimado. Este es el mismo plan que se muestra cuando
la opción Display Estimated Execution Plan es seleccionada, cuando la
consulta no es realmente ejecutada.

1. Ejecute:

1SET SHOWPLAN_XML ON

2. Note que esta es la única sentencia aquí que puede ser ejecutada.
3. Ejecute una consulta. La pestaña Results mostrará un enlace al plan de
consultas. Note que los resultados de la consulta no son mostrados, ya
que la consulta no es realmente ejecutada.

4. Haga clic en el enlace en la cuadrícula.

Una nueva pestaña de consulta será abierta mostrando el plan de

consultas.

5. Para parar de mostrar el plan de consultas , corra:

1SET SHOWPLAN_XML OFF

Use el caché de la consulta

 Como se mencionó en el artículo Planes de ejecución de consultas SQL Server
– Básicos, los planes de consultas en SQL Server son grabados en el caché del
plan de consultas, así que pueden ser reutilizados para ejecutar consultas más
rápido. Una de las opciones para ver planes de consultas es consultar el
contenido del caché del plan usando Vistas de Administración Dinámicas
(Dynamic Management Views, DMVs).

La vista sys.dm_exec_cached_plans muestra una fila por cada plan de

consultas almacenado en el caché de planes. La vista muestra texto de
consultas, la memoria usada y cuántas veces el plan fue reutilizado.

La vista sys.dm_exec_sql_text muestra el texto SQL, identificado por

sql_handle.

Para ver los planes para consultas ad hoc en el caché de planes:

1 SELECT qp.query_plan,
2 CP.usecounts,
3 cp.cacheobjtype,
4 cp.size_in_bytes,
5 cp.usecounts,
6 SQLText.text
7 FROM sys.dm_exec_cached_plans AS CP
8 CROSS APPLY sys.dm_exec_sql_text( plan_handle)AS SQLText
9 CROSS APPLY sys.dm_exec_query_plan( plan_handle)AS QP
10 WHERE objtype = 'Adhoc' and cp.cacheobjtype = 'Compiled Plan'

Para abrir un plan, haga clic en el enlace en la columna de resultados

query_plan y el plan será mostrado en la ventana de nueva Consulta.

Use las opciones STATISTICS y SHOWPLAN

 La opción STATISTICS XML muestra el mismo plan de consultas que la
opción Include Actual Execution Plan. A diferencia de las opciones SHOWPLAN
que no ejecutan las consultas realmente, las opciones STATISTICS lo ejecutan
y muestran los resultados.

1SET STATISTICS XML ON

Note que aparte del enlace al plan de consultas, los resultados de la consulta
son también mostrados.

Para apagar la opción, ejecute:

1SET STATISTICS XML OFF

Otras opciones útiles son:

SHOWPLAN_XML – no ejecuta la consulta, así que no se muestran resultados.

Muestra el enlace al igual que la opción STATISTICS XML.

SHOWPLAN_TEXT – no ejecuta la consulta, muestra el texto del plan de

consultas estimado.
SHOWPLAN_ALL – no ejecuta la consulta, muestra el texto del plan de
consultas estimado junto con el costo de la estimación.

STATISTICS PROFILE – ejecuta la consulta, muestra los resultados y texto del

plan de consultas real.

Use SQL Server Profiler

Una plan de ejecución también puede ser capturado en un rastro de SQL

Server y abierto en SQL Server Profiler.

1. Inicie SQL Server Profiler

2. En el menú File, seleccione New Trace
3. En la pestaña Events Selection, seleccione Show all events
4. Expanda el nodo Performance
5. Seleccione Showplan XML
 6. Ejecute la consulta para la que quiere ver el plan de consultas
7. Pare el rastro. Esto es recomendado debido a razones prácticas – en
bases de datos ocupadas es difícil filtrar el evento que desea rastrear
8. Seleccione el plan de consultas en la cuadrícula

El plan de consultas SQL Server es mostrado en el panel inferior. Es el

mismo plan mostrado cuando la opción Include Actual Execution
Plan es seleccionada. Usted puede ver sus detalles en la sugerencia que
aparece cuando se pasa el ratón por encima o se graba todo el rastro
como un archivo XML para su análisis posterior.

Este método no es recomendado debido a muchas desventajas. SQL Server

Profile añade algo de costo que afecta el desempeño de la consulta. Otra razón
es que filtrar los eventos y encontrar el específico entre miles de registros no
es fácil en SQL Server Profiler.

En este artículo mostramos cómo abrir un plan de ejecución de consultas SQL

Server usando varios métodos. En el siguiente artículo, mostraremos cómo
leer los planes, qué representan los objetos representados con íconos, y cómo
usar estos planes en análisis de desempeño y solución de problemas.
Recursos:

• Display an Actual Execution Plan

• Graphical Execution Plan Icons (SQL Server Management Studio)
• sys.dm_exec_query_stats (Transact-SQL)

See more

Check out ApexSQL Plan, to view SQL execution plans, including comparing
plans, stored procedure performance profiling, missing index details, lazy
profiling, wait times, plan execution history and more

Milena Petrovic
Milena es una profesional de SQL Server con más de 20 años de experiencia en
IT. Ella ha iniciado con programación de computadoras en la escuela
secundaria y continuó en la Universidad.
Ella ha estado trabajando con SQL Server desde 2005 y tiene experiencia con
SQL 2000 hasta SQL 2014.
Su tema favorito de SQL Server son las recuperaciones de desastres, la
auditoría y el monitoreo de desempeño.

Vea todas las entradas de Milena “Millie” Petrovic

Related Posts:

1. Técnicas de optimización de consultas en SQL Server: consejos y trucos

de aplicación
2. Almacén de consultas de SQL Server – Descripción general
3. Las 10 preguntas y respuestas más importantes sobre los índices de
SQL Server
4. Varias técnicas para auditar bases de datos de SQL Server
5. Una vista dentro de la caché del búfer de SQL Server
 EGRAFÍA

https://www.sqlshack.com/es/planes-de-ejecucion-de-consultas-sql-server-viendo-los-planes/