Index Scan contra Seek Index

20/12/2005 - 22:57 por Pao | Informe spam
Hola a todos.
Es malo que existan demasiados Index scan...y que muchos Index Seek.
Teoricamente el primero afecta mas el rendimiento del equipo porque de cierta
forma hace una especie de table scan.
Por favor si me ayudan aclarando dudas y conceptos.

Gracias.

Preguntas similare

Leer las respuestas

#6 Alejandro Mesa
22/12/2005 - 15:56 | Informe spam
ulises,

Para nada, porque el clustered index scan se hace sobre las paginas
intermedias del indice.

Chequea el "Estimate IO" en el siguiente script. Tambien puedes activar "set
statistics io on" para que compares las lecturas.

use northwind
go

select *
into t1
from orders
go

select *
into t2
from orders
go

create unique clustered index ix_u_c_t2_orderid on t2(orderid asc)
go

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
go

set statistics profile on
go

select orderid from t1
select orderid from t2
go

set statistics profile off
go

drop table t1, t2
go


AMB


"ulises" wrote:

Mostrar la cita
#7 ulises
23/12/2005 - 00:08 | Informe spam
Interesante ..., ejecute tu código pero no encontré mucha diferencia en las
lecturas (siendo t2 la tabla con cluster index) :

Table 't1'. Scan count 1, logical reads 21, physical reads 0, read-ahead
reads 20.
Table 't2'. Scan count 1, logical reads 21, physical reads 1, read-ahead
reads 20.

aunque lo que muestra como I/O Cost es ligeramente menor en el caso del
clustered index scan. Ahora bien, si en la definición del cluster le quitamos
la opción de UNIQUE el I/O Cost es identico en ambos casos y las lecturas me
marcaron :

Table 't1'. Scan count 1, logical reads 21, physical reads 0, read-ahead
reads 20.
Table 't2'. Scan count 1, logical reads 22, physical reads 2, read-ahead
reads 20.

... creo que amerita que le dé una mirada más profunda ... :)
Saludos,
Ulises


"Alejandro Mesa" wrote:

Mostrar la cita
#8 Alejandro Mesa
23/12/2005 - 14:44 | Informe spam
Ulises,

Esta es una tabla pequeña y quizas no podamos ver mucha diferencia. Dejame
refrasear lo dicho anteriormente, si tenemos que leer toda la data en la
tabla, un scan del indice clustered tomara igual o quizas un poco mas de
tiempo (hay que leer nodos intermedios y los de data o leaf) que si hacemos
un scan de la tabla, cosa que no nos asombra. Pero si en cambio, la
informacion que necesitamos esta en el indice (valores de las columnas que
conforman la clave), sql server no necesitara leer los nodos que contienen la
data y esto sera independiente de si el indice es clustered o no.


AMB

"ulises" wrote:

Mostrar la cita
#9 ulises
23/12/2005 - 16:22 | Informe spam
Pero ese es precisamente el punto, en un clustered index la página de datos
es el nodo más bajo de los índices (cosa diferente con un non-clustered
index donde necesita crear uno ya que tiene que ordenarlo) y por lo tanto
tiene que leerlo para obtener la información.

En todo caso voy a probar tu código con varios millones de filas para ver
como se comporta (pero eso será a partir del próximo año ... hay varias
mujeres que me mantendrán muy ocupado por lo que resta del año -- mi esposa
y mis hijas --) :)

Saludos,
Ulises

"Alejandro Mesa" wrote:

Mostrar la cita
#10 Alejandro Mesa
23/12/2005 - 17:30 | Informe spam
Ulises,

No pierdas tu tiempo. Yo soy quien esta equivocado :(
y pido disculpas a Maxi y a ti. Yo estava pensando en la utilidad de los
indices nonclustered que son covering (las claves del indice incluyen todas
las columnas que se referencian en el query) y por tanto no hace falta ir a
la tabla para leer estos datos y como el indice contiene menos columnas que
la tabla, entonces cabran mas filas por pagina y por lo tanto menos
operaciones de IO haran falta para escanearlo, comparado con scanear la tabla.

Como ustedes dijeron anteriormente, el scan sobre el indice clustered
equivale a leer toda la tabla pero de forma ordenada, osea, la lectura de las
paginas de data se programaran en el orden del indice, pero de todas maneras
habra que leer los nodos leaf, que en este caso es la tabla.

En esto era en lo que pensava.

use northwind
go

select *
into t1
from orders

select *
into t2
from orders

create unique clustered index ix_u_c_t1_orderid on t1(orderid asc)
create unique nonclustered index ix_u_nc_t2_orderid on t2(orderid asc)
go

dbcc dropcleanbuffers
dbcc freeproccache
go

set statistics io on
go

set statistics profile on
go

select orderid from t1
select orderid from t2
go

set statistics profile off
go

set statistics io off
go

drop tabl t1, t2
go


AMB

"ulises" wrote:

Mostrar la cita
Ads by Google
Search Busqueda sugerida