Mi conclusión sobre particionar tablas

¿ Has considerado poner la fecha como índice clustered ?

Eso podría aumentar mucho el rendimiento si la mayoría de las consultas
tienen un rango de fechas en la cláusula where.

Saludos:

Jesús López
MVP

Vaya Jesús, ayer no pude estar mucho por aquí y me ha sorprendido la
cantidad de respuestas que has publicado... ¿nos vas a acompañar una
temporadita? :-D

PD: también estoy viendo a Eladio, Miguel, Salva... como en los buenos
tiempos, sólo falta "er maeztro"


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"SqlRanger" escribió en el mensaje
news:#k#

¿ Has considerado poner la fecha como índice clustered ?

Eso podría aumentar mucho el rendimiento si la mayoría de las consultas
tienen un rango de fechas en la cláusula where.

Saludos:

Jesús López
MVP

"SqlRanger" wrote in message
news:%23k%

¿ Has considerado poner la fecha como índice clustered ?

Eso podría aumentar mucho el rendimiento si la mayoría de las consultas
tienen un rango de fechas en la cláusula where.

No importa que la clausula where tuviera otras expresiones condicionales
aparte de la relativa a la fecha, tambien aplica igual ese criterio ?

En general, la respuesta es que sí. Porque teniendo un rango de fechas en la
where y un índice agrupado sobre la fecha, jamás SQL Server hará una
exploración completa de la tabla que es lo peor que le puede pasar a una
consulta, aunque haya otras condiciones en la where, combinadas con AND,
claro.

Las consultas que más se benefician de esto son aquellas que antes de ser la
fecha un índice agrupado, se requería una exploración completa de la tabla,
como las que tienen un rango de fechas lo suficientemente grande (de una
semana, un mes o más) y no tienen otras condiciones muy restrictivas con un
índice que usar.

Las consultas que tengan un rango pequeño de fechas también resultarán
beneficiadas porque ya no se tendrán que realizar bookmark lookups para
ejecutar estas consultas.

La pega de tener un índice agrupado sobre la fecha, es el tamaño de la
clave. Toda clave de índice agrupado tiene que ser única. Si en principio no
es única, SQL Server la hace única añadiéndole un unicificador, un entero de
32 bits. Así que si la fecha, preferiblemente smalldatetime, ocupa 4 bytes,
la clave del índice agrupado tiene 8 bytes. Si antes teníamos una clave
agrupada entera, un Id autonumérico por ejemplo que sólo eran 4 bytes, caben
menos claves agrupadas en una página y el árbol del índice podría tener más
niveles con lo que los bookmark lookups se verían perjudicados, al tener que
leer alguna página más para realizar la operación.

La consecuencia de esto último es que si la clave agrupada anterior era más
pequeña, se verán perjudicadas aquellas consultas que tengan un rango grande
de fechas y condiciones adicionales combinadas con and muy restrictivas e
índice disponible. Sin embargo estas consultas se seguirán ejecutando
rápidas porque usan índices.


Siento no poder darte un sí o un no rotundos, pero las cosas son así, por un
lado ganas y por otro pierdes. La decisión debe tomarse en función de si
ganas más de lo que pierdes.


Saludos:

Jesús López
MVP

Os acompañaré siempre que pueda, eso depende de lo liado que esté.

Un abrazo

Jesús