Table Scan y Cluster Index Scan

No siempre los vas a tener que evitar porque no siempre son malos. Puede
ocurrir que sea más eficiente recorrerse toda la tabla que irse a un índice
y luego mostrar los valores que coincidan.

Depende de la situación...

"Ismael" escribió en el mensaje
news:

Hola,

siguiendo con el tema de rendimientos en las base de datos. Leo que hay
que
evitar que en los planes de ejecución aparezca 'Table Scan' o 'Cluster
Index
Scan'. ¿Por qué se producen estos y que técnicas hay para evitarlos?
Gracias
de nuevo :)

Ismael

Ahora mismo no recuerdo algún artículo, pero un ejemplo de que un Table
Scan (o Clustered Index Scan) es bueno es cuando al tabla es pequeña (pocos
registros) o bien cuando el criterio de filtrado (WHERE) no es muy exclusivo

"Ismael" escribió en el mensaje
news:

¿Algún ejemplo de cada uno de los dos casos para saber cuando interesa más
o
dirección a algún artículo que trate este tema? Gracias

"Carlos Sacristan" wrote:

No siempre los vas a tener que evitar porque no siempre son malos.
Puede
ocurrir que sea más eficiente recorrerse toda la tabla que irse a un
índice
y luego mostrar los valores que coincidan.

Depende de la situación...

"Ismael" escribió en el mensaje
news:
> Hola,
>
> siguiendo con el tema de rendimientos en las base de datos. Leo que hay
> que
> evitar que en los planes de ejecución aparezca 'Table Scan' o 'Cluster
> Index
> Scan'. ¿Por qué se producen estos y que técnicas hay para evitarlos?
> Gracias
> de nuevo :)
>
> Ismael

Cuando hablas de un SCAN tienes que tener en cuenta que eso significa leer
de punta a punta, ya sea un indice, la tabla ordenada (cluster index) o
desordenada (heap). Hay alternativas como range scan en ciertos casos.

La ventaja en esos casos es que el Read Ahead funciona muy bien y puede
adelantar lecturas ademas de que se pueden sincronizar y fundir varios SCAN
para que no haga falta hacer mas de uno SQL2000+ , cosa que suele suceder en
los data warehouse.

Cuando es ventajoso el scan, cuando el porcentaje de lecturas es
relativamente grande respecto del total del objeto (tabla o indice).
Si el porcentaje es pequeño en general es mejor un SEEK.

Tienes que tomar en cuenta que el scan aprovecha mejor la rotacion de los
discos ya que lee en forma consecutiva los registros
El seek generalmente requiere en general accesos aleatorios sobre las tablas
cuando no es sobre un indice clustered y por lo tanto requiere que la cabeza
del disco se pocicione sobre el sector a leer. Por lo tanto y a pesar de que
las controladoras y el propio SQL Server tratan de minimizar este efecto
sigue siendo mas eficiente el SCAN si ese % es alto.

Debes tener en cuenta que en el caso de acceder por indice, debes ademas,
leer las estructuras internas de los mismos con lo cual tienes lecturas
adicionales.

Por supuesto hay mas consideraciones pero creo que esto te puede aclarar un
poquito tu duda.

En este mismo momento estoy viendo un caso donde una tabla de 230 millones
de registros la estoy por particionar para que ciertos casos hagan un scan
en lugar de un seek.
Pero en lineas generales (no siempre es asi) si tienes un % bajo lo mejor es
seek y si el % es alto lo mejor es el scan.




Saludos
Ing. Jose Mariano Alvarez


(Cambia los ceros por O y saca lo que sobra)




"Ismael" wrote in message
news:

si por ejemplo se tratara de hacer JOINs ¿se entendería como un criterio
muy
exclusivo? La tabla principal tendría unos 4000 registros y la secundaria
es
una auxiliar de unos 15 registros. ¿Aquí interesaría más el Clustered
Index
Scan? Gracias de nuevo!

Ismael


"Carlos Sacristan" wrote:

Ahora mismo no recuerdo algún artículo, pero un ejemplo de que un
Table
Scan (o Clustered Index Scan) es bueno es cuando al tabla es pequeña
(pocos
registros) o bien cuando el criterio de filtrado (WHERE) no es muy
exclusivo

"Ismael" escribió en el mensaje
news:
> ¿Algún ejemplo de cada uno de los dos casos para saber cuando interesa
> más
> o
> dirección a algún artículo que trate este tema? Gracias
>
> "Carlos Sacristan" wrote:
>
>> No siempre los vas a tener que evitar porque no siempre son malos.
>> Puede
>> ocurrir que sea más eficiente recorrerse toda la tabla que irse a un
>> índice
>> y luego mostrar los valores que coincidan.
>>
>> Depende de la situación...
>>
>> "Ismael" escribió en el mensaje
>> news:
>> > Hola,
>> >
>> > siguiendo con el tema de rendimientos en las base de datos. Leo que
>> > hay
>> > que
>> > evitar que en los planes de ejecución aparezca 'Table Scan' o
>> > 'Cluster
>> > Index
>> > Scan'. ¿Por qué se producen estos y que técnicas hay para evitarlos?
>> > Gracias
>> > de nuevo :)
>> >
>> > Ismael
>>
>>
>>