Búsquedas

Utilizando Índices
El índice es una estructura de árbol, la búsqueda se realiza navegando desde la página raíz hasta llegar al
nivel final (Leaf Level). El valor de la clave se encuentra repartido en esos diferentes niveles del índice.

Figure 34. Estrura multinivel, imagen tomada de: https://grimpidev.wordpress.com/2008/03/08/diferencias-entre-clustered-
y-non-clustered-index-en-sql-server/

Para tratar de entender un poco como se llevan a cabo las búsquedas de registros dentro de la base de
datos, vamos a comenzar analizando las siguientes figuras, estas gráficas muestran la estructura de los
índices multiniveles agrupados (CLUSTERED) y los secundarios o no agrupados (NONCLUSTERED).

Figure 35. Índice agrupado (Clustered). Imagen tomada de: http://questpond.over-blog.com/article-sql-server-interview-

questions-can-you-explain-clustered-index-and-non-clustered-index-97444471.html

En índice de agrupado vamos a tener una página o nodo raíz. Esta página referencia a un segundo nivel
de índice. A su vez, este nivel referencia las páginas de datos. En resumen, todo comienza en un nodo
raíz hasta llegar a un último nivel del índice que referencie las páginas finales (Leaf Nodes), que en este

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 86

son las mismas páginas de datos. En un índice Clustered los datos son parte de la propia estructura del
índice.

Figure 36. Índice no agrupado (Nonclustered). Imagen tomada de: http://questpond.over-blog.com/article-sql-server-
interview-questions-can-you-explain-clustered-index-and-non-clustered-index-97444471.html

En un índice no agrupado, el último nivel del índice referencia a las finales (Leaf Nodes), estas páginas
contienen punteros para saltar a buscar el registro (Bookmark Lookup).

Si una tabla no tiene índice la búsqueda se realiza directamente sobre las páginas de datos.

Figure 37. Clustered - Nonclustered, Imagen tomada de: https://grimpidev.wordpress.com/2008/03/08/diferencias-entre-
clustered-y-non-clustered-index-en-sql-server/

Cuando se realiza una consulta el manejador activa un proceso que se llama “Optimizador de
consultas”, este proceso se encarga de analizar la sentencia y determinar la forma más rápida para traer
esos registros, basándose para ellos en muchos factores tales como: la forma de la consulta, los índices
de la tabla, el volumen de registros, etc.

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 87

Para traer los registros cualquiera de las siguientes operaciones puede ser ejecutada:

a) Table Scan: Es una búsqueda completa sobre las páginas de datos, se realiza normalmente si la
tabla no tiene índice.
b) Index Scan: Es una búsqueda completa sobre el índice, se utiliza el índice pero como la consulta
o tiene filtro se debe buscar en el índice completo.
c) Index Seek: Es una búsqueda selectiva sobre el índice, se utiliza el índice y como la consulta
tiene filtro se puede discriminar o hacer saltos específicos.
d) Clustered Index Scan/Seek: Lo mismo mencionado anteriormente, pero sobre un índice
“Clustered”.
e) RowID Lookup: Es un salto a la página de datos tomando como base el Row ID. Esto se hace
cuando se busca en un índice Nunclustered y la tabla no tiene clave primaria o algún índice
Clustered. Recuerda que la última página del índex se tiene un puntero que refiere al lugar
donde se encuentran los datos, ese lookup se refiere a ese salto utilizando ese puntero.
f) Key Lookup: Es el mismo punto anterior, sólo que como la clave tiene un índice Clustered
entonces, el salto es por el índice Clustered, no por el Row ID.

Para ver como se generan alguna de las operaciones mencionadas vamos a crear un “script”. Este
“script” crea una tabla e inserta varios registros mediante un bloque de programación, tres versiones del
mismo script para que puedas jugar en cualquier de los tres manejadores:

SQL SERVER:

Create table cliente(id int not null,nombre varchar(60),tipo int,cedula varchar(20))

go
declare @n int
declare @s varchar(20)
set @n=1

while @n<50000
begin
SET @s=cast(@n as varchar(10))
Insert into cliente values(@n,'nom '+@s,1,'ced'+@s)
SET @n=@n+1
end

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 88

MySQL:

Create table cliente(id int not null,nombre varchar(60),tipo int,cedula varchar(20));

delimiter//
create procedure p2()
begin

declare n int default 0;

set n=1;
while n<50000 do
insert into cliente values
(n,concat(n,'nom ',n),1,concat('ced',n));
SET n=n+1;
End while;

end
//
delimiter;

call p2();

ORACLE:

Create table cliente(id int not null,nombre varchar(60),tipo int,cedula varchar(20));

declare
n int;
begin
n:=1;
while n<50000
loop
insert into cliente values
(n,'nom '||n,1,'ced' || n);
n:=n+1;
end loop;
end;

Primero voy a utilizar una opción de SQL SERVER llamada “statisticsio”. Esta opción me da
información sobre el proceso de lectura lógica y física para traer los datos. Vamos a ver los resultados
buscando con índice y sin índices. Ahora mismo, la tabla solo está creada y tiene muchos datos. No hay
ni siquiera PK. Vamos a ejecutar la siguiente consulta y cuando el resultado se muestre, observa la
pestaña “Messages”. Ahí se muestran las informaciones que necesitamos ver.

Set statistics io on
go
select * from cliente where cedula='ced40000'

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 89

El resulado obtenido es:

(1 row(s) affected)
Table 'cliente'. Scan count 1, logical reads 257, physical reads 0,

Nos está diciendo que estuvo leyendo 257 páginas en memoria (Logical Reads) para llegar a registro
que se buscaba. No hubo lectura física (del disco) porque ya se habían hecho otras operaciones con esa
tabla en la misma sesión.

Ahora vamos a crear un índice por la columna “cédula” y analicemos el resultado nueva vez:

Create index idx_cliente on cliente(cedula)

Luego otra vez:

Set statistics io on
go
select * from cliente where cedula='ced40000'

Resultado:

Table 'cliente'. Scan count 1, logical reads 3

Esta vez, el resultado dice que utilizando el índice sólo tuvo que buscar en tres páginas para localizar el
dato.

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 90

Analizando el Tipo de Búsqueda

Vamos a continuar con esto ejemplo anterior:

Tenemos una tabla llamada “cliente”. Vamos a ponerla sin ningún índice y analicemos el tipo de
búsqueda que se generada con cada consulta.

Para este ejercicio, vamos a utilizar la opción de SQL SERVER llamada “ Display Estimated Execution
Plan”, sólo tienes que sombrear al sentencia SQL y ejecutar este botón en la barra de botones. Eso te
debe mostrar el plan que el optimizar tiene para buscar esos registros. En el caso de MySQL, puedes
agregar a tu script la sentencia “explain extended” para lograr algo similar. En ORACLE puedes utilizar
“Explain plan for”.

Caso 1: La tabla no tiene índice de ningún tipo, se ejecuta una búsqueda completa sobre la tabla.

Caso 2: Vamos a crear un PK. Vemos que ejecuta un “Clustered Index Seek”, una búsqueda selectiva
sobre el índice Clustered.

Alter table cliente add constraint pk_cliente primary key(id)

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 91



Caso 3. La tabla tiene una llave primaria. Pero voy a utilizar una sentencia sin filtro. Vemos que la
búsqueda sigue siendo sobre el índice pero un “Scan”.

Igual resultado podríamos ver si la búsqueda incluye un filtro, pero sobre una columna que no es parte
de la clave, por ejemplo:

Select * from cliente where cedula='ced30000'

Caso 4. Teniendo un PK vamos a agregar un índice no agrupado, cuando se utiliza el índice Nonclustered
primero se busca en el índice y luego, se hace un saldo “Key Lookp” hacia los datos.

Create index idx_cliente on cliente(cedula)

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 92



Caso 5: Si borramos el “Primary Key” y dejamos el índice no agrupado, veremos que el salto es de tipo
“Row id Lookup”.

INTRODUCCION BASES DE DATOS – Ing. Carlos Caraballo Page 93