1

Optimizacin del rendimiento de

las consultas de SQL Server

Al optimizar el servidor de la base de datos, necesita
tambin mejorar el rendimiento de las consultas
individuales. Esto es igual de importante, o incluso
ms, que optimizar otros aspectos de la instalacin del
servidor, aspectos que afectan al rendimiento, como las
configuraciones de hardware y software.
Incluso si el servidor de la base de datos se ejecuta en el hardware ms eficaz, su
rendimiento puede verse afectado negativamente por un conjunto de consultas que se
comporten incorrectamente. De hecho, incluso una sola consulta incorrecta, a veces
denominada "consulta descontrolada", puede provocar serios problemas de rendimiento a la
base de datos.
De manera opuesta, el rendimiento general de la base de datos puede mejorarse en gran
medida al optimizar el conjunto de las consultas ms costosas o que se ejecutan con mayor
frecuencia. En este artculo, tratar algunas de las tcnicas que puede emplear para
identificar y optimizar las consultas ms costosas y las de peor rendimiento del servidor.

Anlisis de los planes de ejecucin
Para optimizar una consulta individual, normalmente se empieza observando el plan de
ejecucin de esa consulta. El plan de ejecucin describe la secuencia de operaciones, fsicas
y lgicas, que SQL ServerTM realizar con el objeto de cumplir la consulta y producir el
conjunto de resultados deseado. El plan de ejecucin lo genera un componente motor de
la base de datos llamado Optimizador de consultas durante la fase de optimizacin del
procesamiento de la consulta, esto tiene en cuenta muchos factores diferentes, como los
predicados de bsqueda en la consulta, las tablas implicadas y sus condiciones de
combinacin, la lista de columnas devueltas y la presencia de ndices tiles que pueden
servir como rutas de acceso eficaces a los datos.
Para las consultas ms complejas, el nmero de todas las permutaciones posibles puede ser
muy grande, por lo que el optimizador de consultas no evala todas posibilidades, sino que
en su lugar intenta encontrar un plan que sea "lo suficientemente bueno" para una consulta
determinada. Esto es porque el encontrar un plan perfecto no siempre es posible; e incluso
cuando es posible, el costo de la evaluacin de todas las posibilidades para encontrar que
el plan perfecto podra fcilmente tener ms peso que cualquier ganancia de rendimiento.
Desde el punto de vista de los administradores de bases de datos, es importante
comprender el proceso y sus limitaciones.
Hay varias maneras de recuperar un plan de ejecucin para una consulta:
Management Studio proporciona las caractersticas Mostrar el plan de ejecucin real y Mostrar el plan de ejecucin estimado, que presentan el plan de una manera
grfica. Estas caractersticas ofrecen la solucin ms conveniente para el examen directo y constituyen, sin duda, el enfoque usado con ms frecuencia para mostrar y
analizar los planes de ejecucin. (En este artculo, usar los planes grficos generados de este modo para ilustrar mis ejemplos).
2

Varias opciones SET, como SHOWPLAN_XML y SHOWPLAN_ALL, devuelven el plan de ejecucin en forma de documento XML que describe el plan mediante un
esquema o como un conjunto de filas con descripciones textuales de cada una de las operaciones en el plan de ejecucin.
Las clases de evento del Analizador de SQL Server, como Showplan XML, le permiten reunir los planes de ejecucin de instrucciones recopiladas gracias al seguimiento.
Aunque una representacin XML del plan de ejecucin puede no ser el formato ms
sencillo para que las personas lo lean, esta opcin le permite escribir los procedimientos y
utilidades que pueden analizar sus planes de ejecucin, buscar signos de problemas de
rendimiento y planes poco ptimos. Una representacin basada en XML tambin puede
guardarse en un archivo con la extensin .sqlplan y abrirse, a continuacin, en Management
Studio para producir una representacin grfica. Estos archivos pueden guardarse tambin
para un anlisis posterior, eliminando, por supuesto, la necesidad de reproducir el plan de
la ejecucin cada vez que desee analizarlo. Esto es especialmente til cuando desea
comparar sus planes para ver cmo cambian con el tiempo.

Costo estimado de la ejecucin
Lo primero que tiene que entender acerca de los planes de ejecucin es cmo se generan.
SQL Server usa un optimizador de consultas basado en el costo, es decir, intenta generar un
plan de ejecucin con el costo estimado ms bajo. La estimacin se basa en las estadsticas
de distribucin de datos que estn disponibles para el optimizador cuando evala cada
tabla implicada en la consulta. Si esas estadsticas se pierden o quedan obsoletas, el
optimizador de consultas carecer de la informacin esencial necesaria para el proceso de
optimizacin de consultas y, por lo tanto, es probable que las estimaciones queden fuera
de la marca. En dichos casos, el optimizador seleccionar un plan menos ptimo tanto
sobrestimando como subestimando los costos de ejecucin de los distintos planes.
Hay algunas suposiciones falsas muy comunes acerca del costo estimado de ejecucin. En
particular, con frecuencia las personas asumen que el costo estimado de ejecucin es un
buen indicador de cunto tiempo tardar la consulta en ejecutarse y que esta estimacin
les permite distinguir los planes buenos de los que no lo son. Esto no es verdad. En primer
lugar, existe la suficiente documentacin sobre lo que son las unidades para expresar el
costo estimado y si stas tienen alguna relacin directa con el tiempo de ejecucin. En
segundo lugar, puesto que se trata de una estimacin y podra estar equivocada, en
ocasiones los planes con costos estimados ms altos pueden ser mucho ms efectivos en
trminos de CPU, E/S y del tiempo de ejecucin, a pesar de que sus estimaciones sean ms
altas. Este caso se suele dar con las consultas que implican variables de tabla, ya que para
stas no hay estadsticas disponibles, el optimizador de consultas siempre asume que una
variable de tabla contiene slo un fila, aunque contenga un nmero mucho mayor. Adems,
el optimizador de consultas elegir un plan basado en una estimacin inexacta. Por lo
tanto, al comparar los planes de ejecucin de las consultas, no debe depender nicamente
del costo estimado de la consulta. En su lugar, incluya el resultado de las opciones
STATISTICS I/O y STATISTICS TIME en el anlisis, para entender cul es realmente el costo
de la ejecucin en trminos de E/S y tiempo de la CPU.
Merece tambin la pena mencionar aqu un tipo especial de plan de ejecucin, llamado
plan paralelo. Si ejecuta su consulta en un servidor con ms de una CPU y su consulta
puede optar por la paralelizacin, puede que se elija un plan paralelo. (Generalmente, el
optimizador de consultas slo considerar un plan paralelo para una consulta que tenga un
costo que supere cierto umbral configurable). Debido a la sobrecarga generada al
administrar mltiples subprocesos paralelos de ejecucin (lo cual implica distribuir el
trabajo a travs de los subprocesos, llevar a cabo la sincronizacin y reunir los resultados),
3

los planes paralelos son ms costosos de ejecutar y eso se refleja en su costo estimado. As
que, por qu se eligen frente a planes ms baratos que no son paralelos? Gracias al uso de
la eficacia de procesamiento de varias CPU, los planes paralelos tienden a generar los
resultados ms rpido que los planes estndar. Dependiendo de su situacin especfica,
incluidas variables como los recursos disponibles y la carga simultnea de otras consultas,
esta situacin puede ser deseable para su instalacin. Si ste fuera el caso, debe controlar
cul de sus consultas puede producir planes paralelos y cuntas CPU pueden usar cada
uno. Esto lo puede hacer configurando el grado mximo de la opcin de paralelismo en el
nivel de servidor e invalidndolo en el nivel de consulta individual con OPTION (MAXDOP
n) tal como considere necesario.

Anlisis de un plan de ejecucin
Ahora me centrar en una consulta sencilla, en su plan de ejecucin y en algunos mtodos
para mejorar su rendimiento. Supongamos que ejecuto esta consulta mediante
Management Studio con la opcin Incluir plan de ejecucin real activada en la base de
datos de ejemplo de Adventure Works en SQL Server 2005:


Copiar cdigo
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
Como resultado, veo el plan de ejecucin descrito en la figura 1. Esta consulta sencilla
calcula la cantidad total de pedidos realizados por cada cliente de Adventure Works. Al
observar el plan de ejecucin, puede consultar cmo el motor de la base de datos procesa
la consulta y produce el resultado. Los planes de ejecucin grficos deben leerse de arriba a
abajo y de derecha a izquierda. Cada icono representa una operacin lgica y fsica
realizada y las flechas muestran flujo de datos entre las operaciones. El grosor de las flechas
representa el nmero de filas que se transmite entre las operaciones, cuanto ms gruesa es
la flecha, ms filas habr implicadas. Si coloca el puntero sobre uno de los iconos del
operador, la informacin sobre herramientas en color amarillo (como la mostrada en la
figura 2) mostrar detalles de esa operacin en particular.

Figura 1 Plan de ejecucin de ejemplo (Hacer clic en la imagen para ampliarla)
4



Figura 2 Detalles sobre una operacin (Hacer clic en la imagen para ampliarla)
Observando cada uno de los operadores, puede analizar la secuencia de pasos realizados:
1. El motor de la base de datos realiza una operacin Clustered Index Scan en la tabla Sales.Customer y devuelve la columna CustomerID para todas las filas de esa tabla.
2. A continuacin, realiza un Index Scan (lo cual significa que realiza un examen de ndice no agrupado) en uno de los ndices de la tabla Sales.SalesOrderHeader. ste es
un ndice de la columna CustomerID, pero tambin incluye implcitamente la columna SalesOrderID (la clave de clster de la tabla). El examen devuelve los valores de
ambas columnas.
3. El resultado de ambos exmenes se une en la columna CustomerID mediante el operador fsico Merge Join. (Esta es una de tres maneras fsicas posibles de realizar una
operacin de unin lgica. Es rpido pero requiere la reorganizacin de ambas entradas en una columna unida. En este caso, ambas operaciones de examen ya han
devuelto las filas reorganizadas en CustomerID, por lo que no hay necesidad de realizar la operacin Ordenar adicional).
4. A continuacin, el motor de la base de datos realiza un examen del ndice agrupado en la tabla Sales.SalesOrderDetail, recuperando los valores de cuatro columnas
(SalesOrderID, OrderQty, UnitPrice y UnitPriceDiscount) de todas filas en esta tabla. (Se haba estimado que esta operacin devolvera 123.317 filas y esa fue la cifra
realmente devuelta, tal como puede observar en las propiedades de nmero estimado de filas y nmero real de filas de la figura 2, por lo que la estimacin fue
bastante acertada).
5. Las filas producidas por el examen de ndice agrupado se transmiten al primer operador Compute Scalar de manera que el valor de la columna calculada LineTotal
pueda calcularse para cada fila, segn las columnas OrderQty, UnitPrice y UnitPriceDiscount implicadas en la frmula.
5

6. El segundo operador Compute Scalar aplica la funcin ISNULL al resultado del clculo anterior, tal como lo requiera la frmula de la columna calculada. Esto completa
el clculo de la columna LineTotal y lo devuelve, junto con la columna SalesOrderID, al operador siguiente.
7. El resultado del operador Merge Join del paso 3 se une con el resultado del operador Compute Scalar del paso 6, mediante el operador fsico Hash Match.
8. A continuacin, se aplica otro operador Hash Match para agrupar las filas devueltas de Merge Join por el valor de la columna CustomerID y el agregado calculado
SUM de la columna LineTotal.
9. El ltimo nodo, SELECT, no es un operador fsico ni lgico, sino ms bien un marcador de posicin que representa los resultados de consulta generales y el costo.
En mi equipo porttil, este plan de ejecucin tuvo un costo estimado de 3,31365 (como se
muestra en la figura 3). Cuando se ejecut con STATISTICS I/O ON, la consulta notific la
realizacin de un total de 1.388 operaciones de lectura lgicas en las tres tablas implicadas.
Los porcentajes que se muestran bajo cada uno de los operadores representan el costo de
cada operador individual en relacin al costo general estimado de todo el plan de
ejecucin. Si observa el plan de la figura 1, puede ver que la mayor parte del costo total de
todo el plan de ejecucin se asocia con los tres operadores siguientes: el Clustered Index
Scan de la tabla Sales.SalesOrderDetail y los dos operadores Hash Match. Pero antes de
seguir con la optimizacin de stos, me gustara sealar un cambio muy sencillo en mi
consulta que me permitir eliminar dos de los operadores por completo.

Figura 3 Costo total estimado de ejecucin de la consulta
Puesto que la nica columna que devuelvo de la tabla Sales.Customer es CustomerID y esta
columna se incluye tambin como una clave externa en Sales.SalesOrderHeaderTable,
puedo eliminar completamente la tabla Customer de la consulta sin cambiar el significado
lgico o el resultado producido por nuestra consulta mediante este cdigo:

Copiar cdigo
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Esto produce un plan de ejecucin distinto, que se muestra en la figura 4.
6


Figura 4 Plan de ejecucin despus de eliminar la tabla Customer de la consulta (Hacer
clic en la imagen para ampliarla)
Se eliminaron por completo dos operaciones, Clustered Index Scan en la tabla Customer y
Merge Join entre Customer y SalesOrderHeader, y la unin Hash Match se sustituy por
Merge Join, que es ms eficaz. Sin embargo, para usar Merge Join entre las tablas
SalesOrderHeader y SalesOrderDetail, se tuvieron que devolver las filas de ambas tablas
clasificadas por la columna de unin SalesOrderID. Para conseguirlo, el optimizador de
consultas decidi realizar un Clustered Index Scan en la tabla SalesOrderHeader, en lugar
de usar un Non-Clustered Index Scan, que hubiera sido ms barato en trminos de la E/S
implicada. Se trata de un buen ejemplo sobre cmo trabaja en la prctica el optimizador,
puesto que los ahorros en el costo por cambiar la manera fsica de llevar a cabo la
operacin de unin fueron mayores que los costos de E/S adicionales generados por el
Clustered Index Scan, el optimizador de consultas eligi la combinacin resultante de
operadores porque ofreci el costo total estimado de ejecucin ms reducido posible. En
mi equipo porttil, aunque el nmero de lecturas lgicas subi (a 1.941), el tiempo de CPU
consumido fue realmente ms pequeo y el costo de ejecucin estimado de esta consulta
se redujo alrededor de un 13 por ciento (2,89548).
Digamos que deseo mejorar an ms el rendimiento de esta consulta. Ahora observo el
Clustered Index Scan de la tabla SalesOrderHeader, que se ha convertido en el operador
ms caro de este plan de ejecucin. Puesto que slo necesito dos columnas de esta tabla
para llevar a cabo la consulta, puedo crear un ndice no agrupado que contenga slo esas
dos columnas, reemplazando el examen de toda la tabla por uno del ndice no agrupado,
mucho ms pequeo. La definicin del ndice puede que tenga este aspecto:

Copiar cdigo
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Tenga en cuenta que el ndice que he creado incluye una columna calculada. Esto no es
siempre posible, dependiendo de la definicin de la columna calculada.
Despus que crear este ndice y ejecutar la misma consulta, obtengo el nuevo plan de
ejecucin mostrado en la figura 5.

Figura 5 Plan de ejecucin optimizado (Hacer clic en la imagen para ampliarla)
El Clustered Index Scan de la tabla SalesOrderDetail se ha reemplazado por un Non-
Clustered Index Scan con un costo de E/S mucho ms reducido. Tambin he eliminado uno
de los operadores Compute Scalar, puesto que mi ndice incluye un valor ya calculado de la
columna LineTotal. El costo estimado del plan de ejecucin es ahora 2,28112 y la consulta
realiza 1.125 lecturas lgicas cuando se ejecuta.

El ndice de cobertura
Ejercicio de consulta de pedido del cliente
7

P Aqu tiene un ejercicio de consulta de pedido del cliente:
trate de averiguar la definicin del ndice, qu columnas
debe contener para convertirse en un ndice de cobertura
para esta consulta y si el orden de las columnas en la
definicin del ndice provocara alguna diferencia en el
rendimiento.
R Le ret a averiguar cul sera el ndice de cobertura ms
ptimo de la tabla Sales.SalesOrderHeader para la consulta
de ejemplo en mi artculo. Para conseguirlo, lo primero que
debe tener en cuenta es que la consulta usa slo dos
columnas de la tabla: CustomerID y SalesOrderID. Si ha
ledo mi artculo detenidamente, habr advertido que en el
caso de la tabla SalesOrderHeader, ya hay un ndice
existente que cubre esta consulta, se trata del ndice en
CustomerID y contiene implcitamente la columna
SalesOrderID, que es la clave de clster de la tabla.
Por supuesto, expliqu tambin por qu el optimizador de consultas decidi no usar este
ndice. S, podra forzar al optimizador de consultas a usar este ndice, pero la solucin sera
menos eficiente que el plan existente que usa los operadores Clustered Index Scan y Merge
Join. Esto es porque estara forzando al optimizador de consultas a elegir entre realizar una
operacin Sort adicional para poder seguir usando Merge Join o retroceder y usar un Hash
Join menos efectivo. Ambas opciones tienen un costo estimado de ejecucin ms alto que
el plan existente (la versin con la operacin Sort funcionara bastante mal), as que el
optimizador de consultas no las usar a menos que se le obligue. As pues, en esta
situacin, el nico ndice que funcionara mejor que el Clustered Index Scan sera un Non-
Clustered Index Scan en SalesOrderID, CustomerID. Pero es importante tener en cuenta que
las columnas deben estar en ese orden exacto:

Copiar cdigo
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Si crea este ndice, el plan de ejecucin contendr el Index Scan y no el operador Clustered
Index Scan. Esto constituye una diferencia considerable. En este caso, el ndice no agrupado
que contiene slo dos columnas es mucho ms pequeo que toda la tabla en forma de
ndice agrupado. Por lo tanto, requerir menos E/S para leer los datos necesarios.
8

Este ejemplo muestra tambin como el orden de las columnas del ndice puede tener una
repercusin considerable en la utilidad para el optimizador de consultas. Asegrese de
tener esto en cuenta cuando disee los ndices de varias columnas.

El ndice que he creado en SalesOrderDetail es un ejemplo del llamado "ndice de
cobertura". Se trata de un ndice no agrupado que contiene todas las columnas necesarias
para realizar la consulta, eliminando la necesidad de examinar toda la tabla mediante los
operadores Table Scan o Clustered Index Scan. El ndice es, en esencia, una copia ms
pequea de la tabla, que contiene un subconjunto de columnas de la tabla. Slo esas
columnas necesarias para contestar la consulta (o consultas) se incluyen en el ndice, en
otras palabras, el ndice contiene slo lo que necesita para "cubrir" la consulta.
La creacin de ndices de cobertura para las consultas ms frecuentemente ejecutadas es
una de las tcnicas ms fciles y comunes que se usa en la optimizacin de consultas.
Funciona especialmente bien en situaciones en las que la tabla contiene un nmero de
columnas pero slo algunas de ellas son mencionadas con frecuencia por las consultas. Al
crear uno o ms ndices de cobertura, puede mejorar mucho el rendimiento de las
consultas afectadas, puesto que stas obtendr acceso a una cantidad de datos mucho ms
pequea y, por lo tanto, proporcionarn menos E/S. Existe, sin embargo, un costo oculto
por mantener los ndices adicionales durante las operaciones de modificacin de datos
(INSERT, UPDATE y DELETE). Dependiendo de su entorno y de la relacin entre las consultas
SELECT y las modificaciones de datos, debera juzgar detenidamente si los costos
adicionales de mantenimiento del ndice estn justificados por las mejoras de rendimiento
de consultas.
No tenga miedo de crear ndices de varias columnas en vez de ndices de una sola columna.
stos tienden a ser mucho ms tiles que los ndices de una sola columna y es ms
probable que el optimizador de consultas los use para cubrir la consulta. La mayora de los
ndices de cobertura son ndices de varias columnas.
En el caso de mi consulta de ejemplo, hay todava posibilidad de incorporar alguna mejora
y esta consulta podra optimizarse an ms colocando un ndice de cobertura en la tabla
SalesOrderHeader. Esto elimina el Clustered Index Scan en favor de un Non-Clustered Index
Scan. Esto se lo dejo para que lo haga como ejercicio. Trate de resolver la definicin del
ndice, qu columnas debe contener para convertirse en un ndice de cobertura para esta
consulta y si el orden de las columnas en la definicin del ndice provocara alguna
diferencia en el rendimiento. Consulte la barra lateral del "Ejercicio de consulta de pedido
del cliente" si desea ver la solucin.

Vistas indizadas
Si el rendimiento de mi consulta de ejemplo es muy importante, puedo ir un paso ms
adelante y crear una vista indizada que almacene fsicamente los resultados materializados
de la consulta. Hay ciertos requisitos previos y limitaciones de vistas indizadas, pero si se
puede usar uno, puede mejorar el rendimiento drsticamente. Tenga presente que las vistas
indizadas conllevan un costo ms alto de mantenimiento que los ndices estndar. Como
resultado, debe tener cuidado cuando las use. En este caso, la definicin del ndice tiene
este aspecto:

Copiar cdigo
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
9

AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*)
AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Tenga en cuenta la opcin WITH SCHEMABINDING, que es un requisito previo para crear
un ndice en esa vista y la funcin COUNT_BIG(*), que es necesaria si nuestra definicin del
ndice contiene una funcin agregada (en este ejemplo, SUM). Despus de crear esta vista,
puedo crear un ndice en ella, como ste:

Copiar cdigo
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
Cuando creo este ndice, el resultado de la consulta incluida en la definicin de la vista se
materializa y se almacena fsicamente en disco en el ndice. Tenga en cuenta que todas las
operaciones de modificacin de datos en las tablas base a continuacin actualizan
automticamente los valores de la vista segn su definicin.
Si ahora vuelvo a ejecutar la consulta, lo que suceda depender de la versin de SQL Server
en la que se ejecute. En las versiones Enterprise o Developer, el optimizador de consultas
asociar automticamente esta consulta con la definicin de la vista indizada y usar la vista
indizada en vez de consultar las tablas base implicadas. La figura 6 muestra el plan de
ejecucin producido en este caso. Consiste en una sola operacin, un Clustered Index Scan
del ndice que cre en la vista. El costo estimado de ejecucin es slo 0,09023 y slo realiza
92 lecturas lgicas.

Figura 6 Plan de ejecucin cuando se usa una vista indizada (Hacer clic en la imagen
para ampliarla)
Tambin puede crear y usar esta vista indizada en otras ediciones de SQL Server, pero para
lograr el mismo efecto tiene que cambiar la consulta para hacer referencia a la vista
directamente mediante la sugerencia NOEXPAND, as:

Copiar cdigo
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Cuando puede observar, las vistas indizadas pueden ser una caracterstica muy eficaz si se
usan adecuadamente. Son las ms tiles para optimizar las consultas que realizan
agregaciones sobre grandes cantidades de datos. Si se usa en Enterprise Edition, pueden
beneficiar a muchas consultas sin la necesidad de realizar cambios en el cdigo.

Identificacin de las consultas a optimizar
Cmo identifico las consultas que deben optimizarse? Yo busco las consultas que se
ejecutan con frecuencia, es posible que individualmente no tengan un costo muy alto de
ejecucin, pero el costo agregado de ejecucin puede ser mucho ms alto que el de una
10

consulta ms grande que se ejecuta raramente. No estoy diciendo que no deba optimizar
las grandes, simplemente creo que debe concentrarse en primer lugar en las consultas que
se ejecutan con ms frecuencia. As que, cmo las identifica?
Desgraciadamente, el mtodo ms seguro es algo complicado e implica realizar un
seguimiento de todas las consultas ejecutadas en su servidor y, a continuacin, agruparlas
por sus firmas. (Es decir, texto de consulta con los valores de parmetros reales
reemplazados por marcadores con el objeto de identificar el mismo tipo de consulta,
incluso si se ejecut con valores de parmetro diferentes). Se trata de un proceso
complicado, puesto que las firmas de consulta son difciles de generar. Itzik Ben-Gan
describe una solucin que usa funciones definidas por el usuario de CLR y expresiones
regulares en su libro Inside Microsoft SQL Server 2005: T-SQL Querying.
Existe otro mtodo mucho ms sencillo, pero de alguna manera menos confiable. Puede
confiar en las estadsticas que se mantienen para todas consultas en la memoria cach del
plan de ejecucin y consultarlas mediante vistas dinmicas de administracin. La figura 7
contiene una consulta de ejemplo que le muestra tanto el texto como el plan de ejecucin
de las 20 consultas en la memoria cach con el nmero ms alto acumulado de lecturas
lgicas. Esta consulta resulta muy til para identificar rpidamente las consultas que
generan el nmero ms alto de lecturas lgicas, pero tiene sus limitaciones. Es decir, slo
mostrar las consultas que tienen sus planes en la memoria cach en el momento en el que
ejecuta la consulta. Si algo no se copia en la memoria cach, se perder.
Figure 7 Identificacin de las 20 consultas ms costosas en trminos de E/S de lectura

SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.text)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC

Una vez que haya identificado las de ms escaso rendimiento, observe sus planes de
consulta y busque maneras de mejorar su rendimiento usando algunas de las tcnicas de
indizacin que he descrito en este artculo. Si el resultado es satisfactorio, ser tiempo bien
invertido.
Feliz optimizacin!

LINK: HTTP://TECHNET.MICROSOFT.COM/ES-
ES/MAGAZINE/2007.11.SQLQUERY.ASPX