Recomendacion de indices

Con la opción b cubres las tres consultas.

Eso sí, ya puestos a crear, yo revisaría la documentación de las vistas
indexadas, puesto que lo que estás usando se adapta perfectamente y el
rendimiento es muy bueno.

"Leonardo" <l> escribió en el mensaje
news:

Tengo una tabla 'Transacciones' (tranum, suplidor,valor,fecha) que
contiene transacciones de proveedores.
La PK es tranum (identity). Suplidor es char(4).

Regularmente hago muchas consultas con mucha frecuencia de estas formas:

1) select sum(valor) from transacciones
where suplidor=@suplidor and fecha<@fecha

2) select sum(valor) from transacciones
where suplidor=@suplidor

3) select suplidor, sum(valor) from transacciones
group by suplidor

Estoy por crearle indices para mejorar el rendimiento, pregunto cuales
indices debo crear ?
a) Solo uno por el campo 'Suplidor' ?
b) Solo uno por los campos 'Suplidor,Fecha' ?
c) Crear los dos indices (a) y (b) ?


Leo

Hola Leonardo,

b) Solo uno por los campos 'Suplidor,Fecha' ?

Otra cosa importante aqui es que tipo de indice se debe crear. Si tienes
muchas filas por "suplidor" y el indice que creas es nonclustered, entonces
no sera muy util, pero si el indice es clustered sera de mucha ayuda porque
las transacciones estaran ya agrupadas por "suplidor". En caso de que decidas
usar un indice clustered, debes primero chequear si el indice asociado a tu
clave primaria es clustered, de ser asi entonces debes alterar esa
restriccion para que use un indice nonclustered.

- eliminar restriccion de clave primaria
- crear indice clustered pro (suplidor, fecha), usar valor FILLFACTOR adecuado
- recrear restriccion de clave primaria con indice nonclustered

Si tienes otras opciones, pruebalas y comparalas. No existe una formula
unica en esto de seleccionar indices, pues esta muy asociado a la
distribucion de los valores de las columnas referenciadas.

AMB


"Leonardo" wrote:

Tengo una tabla 'Transacciones' (tranum, suplidor,valor,fecha) que contiene
transacciones de proveedores.
La PK es tranum (identity). Suplidor es char(4).

Regularmente hago muchas consultas con mucha frecuencia de estas formas:

1) select sum(valor) from transacciones
where suplidor=@suplidor and fecha<@fecha

2) select sum(valor) from transacciones
where suplidor=@suplidor

3) select suplidor, sum(valor) from transacciones
group by suplidor

Estoy por crearle indices para mejorar el rendimiento, pregunto cuales
indices debo crear ?
a) Solo uno por el campo 'Suplidor' ?
b) Solo uno por los campos 'Suplidor,Fecha' ?
c) Crear los dos indices (a) y (b) ?


Leo

Hola Alejandro,

¿no crees que lo más recomendable aquí, más que cambiar los campos del
índice agrupado, sería una vista indexada?
En ese caso, tanto si el filtro por "suplidor" es restrictivo como si no, el
rendimiento será bastante bueno. Lo digo porque si
Leonardo pusiera como índice agrupado (suplidor, fecha), puede que se
produzcan divisiones de página si sus valores no son secuenciales y entonces
lo que ganamos por un lado lo perdemos por otro...

"Alejandro Mesa" escribió en el
mensaje news:

Hola Leonardo,

b) Solo uno por los campos 'Suplidor,Fecha' ?

Otra cosa importante aqui es que tipo de indice se debe crear. Si tienes
muchas filas por "suplidor" y el indice que creas es nonclustered,
entonces
no sera muy util, pero si el indice es clustered sera de mucha ayuda
porque
las transacciones estaran ya agrupadas por "suplidor". En caso de que
decidas
usar un indice clustered, debes primero chequear si el indice asociado a
tu
clave primaria es clustered, de ser asi entonces debes alterar esa
restriccion para que use un indice nonclustered.

- eliminar restriccion de clave primaria
- crear indice clustered pro (suplidor, fecha), usar valor FILLFACTOR
adecuado
- recrear restriccion de clave primaria con indice nonclustered

Si tienes otras opciones, pruebalas y comparalas. No existe una formula
unica en esto de seleccionar indices, pues esta muy asociado a la
distribucion de los valores de las columnas referenciadas.

AMB


"Leonardo" wrote:

Tengo una tabla 'Transacciones' (tranum, suplidor,valor,fecha) que
contiene
transacciones de proveedores.
La PK es tranum (identity). Suplidor es char(4).

Regularmente hago muchas consultas con mucha frecuencia de estas formas:

1) select sum(valor) from transacciones
where suplidor=@suplidor and fecha<@fecha

2) select sum(valor) from transacciones
where suplidor=@suplidor

3) select suplidor, sum(valor) from transacciones
group by suplidor

Estoy por crearle indices para mejorar el rendimiento, pregunto cuales
indices debo crear ?
a) Solo uno por el campo 'Suplidor' ?
b) Solo uno por los campos 'Suplidor,Fecha' ?
c) Crear los dos indices (a) y (b) ?


Leo

Hola Carlos,

Puede que asi sea, por eso es bueno hacer pruebas con diferentes opciones.
En cuanto a la fragmentacion de paginas, se debe usar un valor de FILLFACTOR
adecuado y ademas darle mantenimiento a la tabla, de lo contrario solo
pudieramos crear indices clustered cuando los valores son sequenciales, cosa
que no siempre es asi.

Saludos,
Alejandro Mesa

"Carlos Sacristan" wrote:

Hola Alejandro,

¿no crees que lo más recomendable aquí, más que cambiar los campos del
índice agrupado, sería una vista indexada?
En ese caso, tanto si el filtro por "suplidor" es restrictivo como si no, el
rendimiento será bastante bueno. Lo digo porque si
Leonardo pusiera como índice agrupado (suplidor, fecha), puede que se
produzcan divisiones de página si sus valores no son secuenciales y entonces
lo que ganamos por un lado lo perdemos por otro...

"Alejandro Mesa" escribió en el
mensaje news:
> Hola Leonardo,
>
>> b) Solo uno por los campos 'Suplidor,Fecha' ?
>
> Otra cosa importante aqui es que tipo de indice se debe crear. Si tienes
> muchas filas por "suplidor" y el indice que creas es nonclustered,
> entonces
> no sera muy util, pero si el indice es clustered sera de mucha ayuda
> porque
> las transacciones estaran ya agrupadas por "suplidor". En caso de que
> decidas
> usar un indice clustered, debes primero chequear si el indice asociado a
> tu
> clave primaria es clustered, de ser asi entonces debes alterar esa
> restriccion para que use un indice nonclustered.
>
> - eliminar restriccion de clave primaria
> - crear indice clustered pro (suplidor, fecha), usar valor FILLFACTOR
> adecuado
> - recrear restriccion de clave primaria con indice nonclustered
>
> Si tienes otras opciones, pruebalas y comparalas. No existe una formula
> unica en esto de seleccionar indices, pues esta muy asociado a la
> distribucion de los valores de las columnas referenciadas.
>
> AMB
>
>
> "Leonardo" wrote:
>
>> Tengo una tabla 'Transacciones' (tranum, suplidor,valor,fecha) que
>> contiene
>> transacciones de proveedores.
>> La PK es tranum (identity). Suplidor es char(4).
>>
>> Regularmente hago muchas consultas con mucha frecuencia de estas formas:
>>
>> 1) select sum(valor) from transacciones
>> where suplidor=@suplidor and fecha<@fecha
>>
>> 2) select sum(valor) from transacciones
>> where suplidor=@suplidor
>>
>> 3) select suplidor, sum(valor) from transacciones
>> group by suplidor
>>
>> Estoy por crearle indices para mejorar el rendimiento, pregunto cuales
>> indices debo crear ?
>> a) Solo uno por el campo 'Suplidor' ?
>> b) Solo uno por los campos 'Suplidor,Fecha' ?
>> c) Crear los dos indices (a) y (b) ?
>>
>>
>> Leo
>>
>>
>>
>>

Sí, claro, no quería dar la impresión que no se pueden generar índices
agrupados sobre columnas no secuenciales. Tan solo que en el caso que nos
ocupa pienso que probablemente sea mejor solución lo de las vistas
indexadas.

"Alejandro Mesa" escribió en el
mensaje news:

Hola Carlos,

Puede que asi sea, por eso es bueno hacer pruebas con diferentes opciones.
En cuanto a la fragmentacion de paginas, se debe usar un valor de
FILLFACTOR
adecuado y ademas darle mantenimiento a la tabla, de lo contrario solo
pudieramos crear indices clustered cuando los valores son sequenciales,
cosa
que no siempre es asi.

Saludos,
Alejandro Mesa

"Carlos Sacristan" wrote:

Hola Alejandro,

¿no crees que lo más recomendable aquí, más que cambiar los campos
del
índice agrupado, sería una vista indexada?
En ese caso, tanto si el filtro por "suplidor" es restrictivo como si no,
el
rendimiento será bastante bueno. Lo digo porque si
Leonardo pusiera como índice agrupado (suplidor, fecha), puede que se
produzcan divisiones de página si sus valores no son secuenciales y
entonces
lo que ganamos por un lado lo perdemos por otro...

"Alejandro Mesa" escribió en el
mensaje news:
> Hola Leonardo,
>
>> b) Solo uno por los campos 'Suplidor,Fecha' ?
>
> Otra cosa importante aqui es que tipo de indice se debe crear. Si
> tienes
> muchas filas por "suplidor" y el indice que creas es nonclustered,
> entonces
> no sera muy util, pero si el indice es clustered sera de mucha ayuda
> porque
> las transacciones estaran ya agrupadas por "suplidor". En caso de que
> decidas
> usar un indice clustered, debes primero chequear si el indice asociado
> a
> tu
> clave primaria es clustered, de ser asi entonces debes alterar esa
> restriccion para que use un indice nonclustered.
>
> - eliminar restriccion de clave primaria
> - crear indice clustered pro (suplidor, fecha), usar valor FILLFACTOR
> adecuado
> - recrear restriccion de clave primaria con indice nonclustered
>
> Si tienes otras opciones, pruebalas y comparalas. No existe una formula
> unica en esto de seleccionar indices, pues esta muy asociado a la
> distribucion de los valores de las columnas referenciadas.
>
> AMB
>
>
> "Leonardo" wrote:
>
>> Tengo una tabla 'Transacciones' (tranum, suplidor,valor,fecha) que
>> contiene
>> transacciones de proveedores.
>> La PK es tranum (identity). Suplidor es char(4).
>>
>> Regularmente hago muchas consultas con mucha frecuencia de estas
>> formas:
>>
>> 1) select sum(valor) from transacciones
>> where suplidor=@suplidor and fecha<@fecha
>>
>> 2) select sum(valor) from transacciones
>> where suplidor=@suplidor
>>
>> 3) select suplidor, sum(valor) from transacciones
>> group by suplidor
>>
>> Estoy por crearle indices para mejorar el rendimiento, pregunto cuales
>> indices debo crear ?
>> a) Solo uno por el campo 'Suplidor' ?
>> b) Solo uno por los campos 'Suplidor,Fecha' ?
>> c) Crear los dos indices (a) y (b) ?
>>
>>
>> Leo
>>
>>
>>
>>