Inicio > Sql Server 2005 - 2008 > SQL Server determina un plan de Ejecución usando los Indices disponibles y las Estadísticas

SQL Server determina un plan de Ejecución usando los Indices disponibles y las Estadísticas


SQL Server especifica un plan de la ejecución usando índices y estadística disponibles. Trabajando sobre la base AdventureWorks que viene por default con la instalación de SQL Server 2005.

¿Qué es el plan de ejecución?

Cada vez que se ejecuta una consulta en un motor de bases de datos cualesquiera, internamente se ejecutan una serie de operaciones, que varían según la consulta, los datos y obviamente, el motor de base de datos. El conjunto de pasos que tiene que realizar el motor para ejecutar la consulta, se llama Plan de Ejecución.

En el plan de ejecución de podemos encontrar las siguientes operaciones:

1.- Table Scan :  El motor tiene que leer toda la tabla. No se esta usando ningún tipo de índice. En algunos casos, cuando es una tabla chica, un Table Scan es la mejor opción, ya que produce poco overhead. De hecho la tabla puede tener índices y sin embargo el SQL elige usar un table scan porque seria más rápido..
Solución : Ver si la tabla tiene índices y si se están usando correctamente.
CREATE TABLE [TableScan]
(
Campo1 int IDENTITY (1, 1) NOT NULL ,
Campo2 int,
Campo3 char (30)
)
SELECT * FROM TableScan

2.- Clustered Index Scan : El motor recorre toda la tabla. Se realiza en una tabla que tiene un índice Clustered.
CREATE TABLE [ClusteredIndexScan]
(
Campo1 int IDENTITY (1, 1) NOT NULL,
Campo2 int,
Campo3 char (30)
CONSTRAINT [PK_Campo1] PRIMARY KEY CLUSTERED
(
[Campo1]
))

SELECT * FROM ClusteredIndexScan

3.- Clustered Index Seek : Significa que el motor esta usando efectivamente el índice Clustered de la tabla.
DECLARE @Campo1 INT
SET @Campo1 = 0

WHILE @Campo1 <> 10000
BEGIN
INSERT INTO ClusteredIndexScan VALUES (@Campo1,’Clustered Index Seek’)
SET @Campo1 = @Campo1 + 1
END

SELECT * FROM ClusteredIndexScan WHERE Campo1 = 300

4.- Index Seek : Es similar que el Clustered Index Seek, pero con la diferencia de que se usa un indice Non Clustered.

CREATE INDEX [IDX_Campo23] ON [dbo].[ClusteredIndexScan](Campo2,Campo3)

SELECT Campo2 FROM ClusteredIndexScan WHERE Campo2 = 600 and Campo3 = ‘Clustered Index Seek’

5.- Bookmark Lookup : Esta es una operación muy importante, donde hay algunas diferencias entre 2000 y 2005 que vale la pena saber. El Bookmark Lookup indica que SQL Server necesita ejecutar un salto del puntero desde la página de índice a la página de datos de la tabla para recuperar los datos. Esto sucede siempre que tenemos un índice Non Clustered.
Solucion : Hay que limitar los campos que queremos traer en la consulta. Si el campo extraer esta fuera del índice, entonces se ejecutara esto.

6.- Index Scan : Se lee el índice completo de una tabla. Es preferible a un Table Scan, ya que obviamente leer un indice es mas chico que una tabla. Esta operación puede ser por un mal uso (índice), aunque también puede ser que el motor haya seleccionado que esta es la mejor operación. Es muy común un Index Scan en un join o en un ORDER BY o GROUP BY.

7.- Neested Loop Join : Generalmente el más frecuente. Es también el algoritmo más simple de todo. Este operador fisico es usado por el motor cuando tenemos un join entre 2 tablas y la cantidad de registros es relativamente baja. Tambien aplica con cierto tipo de joins (cross joins por ejemplo).

8.- Merge Join : Usada cuando la cantidad de registros a comparar son grandes y están ordenados. Aun si no están ordenadas, el motor puede predecir que es mas rápido ordenar la tabla.

9.- Hash Join : Otro tipo más de join que existe. Usada generalmente cuando las tablas relacionadas no tienen índice en ninguna de los campos a comparar.

10.- Sort: Como el nombre lo indica, esta operación ordena. El Sort solo se hace cuando el campo o los campos que se desean ordenar, no están indexados. A veces esta operación se ejecuta sola, sin que nosotros hayamos puesto en la consulta el ORDER BY, porque el motor necesita ordenar los datos por alguna razón, por ejemplo, para ejecutar un Merge Join.

Estadísticas

Este proceso se basa en estadística. La mala estadística nos llevara a los malos planes de  ejecución. Si un índice se pone en una tabla pequeña, el plan óptimo pudo ser no hacer uso del índice y utilizar una exploración de la tabla. Si la estadística no es actualizada mientras que la tabla crece perceptiblemente, el SQL Server inmóvil asumirá que la tabla es pequeña y utilizar la exploración de la tabla, aunque esto no sea el plan más óptimo.

En la mayoría de los casos es recomendable dejar que el SQL Server automáticamente ponga al día la estadística.
Se ejecutará la siguiente sentencia para establecer las actualizaciones como automáticas:

USE TuBasedeDatos
EXEC sp_dboption ‘TuBasedeDatos’, ‘auto update statistics’, ‘True’

Para las actualizaciones automáticas de estadística sobre una tabla específica ejecutemos el código siguiente:

USE TuBasedeDatos
EXEC sp_autostats TuTabla, ‘ON’

Para actualizar manualmente la estadística sobre la tabla específica ejecutemos el código siguiente:

USE TuBasedeDatos
UPDATE STATISTICS TuTabla

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: