Indices cuales ?

Tamara,

No. Solo debes tener dos indices, uno por cada columna. SQL Server es lo
suficientemente inteligente para usar ambos indices.


AMB

"Tamara" wrote:

Si yo tengo un campo fecha y otro codigo en una tabla y suelo hacer
busquedas frecuentes tango por codigo como por fecha como por codigo+fecha
como por fecha+codigo, se supone que deberia tener un indice para cada caso,
es decir 4 indices ?

Hola, a ver, el orden es importante en los indices, si haces busquedas
fecha,codigo y luego codigo,fecha podes hacer una cosa

1) sistematizar para que todas sean de una sola manera
2) Armar 2 juegos de indices

pd: ojo con los indices, son muy buenos en lo que respecta a lectura de
informacion pero son muy malos a la hora de mantener informacion como seria
los casos de Insert - Update - Delete


Salu2
Maxi


"Tamara" escribió en el mensaje
news:%

Si yo tengo un campo fecha y otro codigo en una tabla y suelo hacer
busquedas frecuentes tango por codigo como por fecha como por codigo+fecha
como por fecha+codigo, se supone que deberia tener un indice para cada
caso, es decir 4 indices ?

Hola,
Me interesa muchiiiisimo tambien este tema. He buscado y no encuentro
escritos que ayuden a uno a mentalizar cuales son los mejores indices para
una tabla.

Hola, a ver, el orden es importante en los indices, si haces busquedas
fecha,codigo y luego codigo,fecha podes hacer una cosa

Te refieres al orden en que se enumeran las columns en el create index o al
orden en que se especifican en la clausula WHERE de un select ?

1) sistematizar para que todas sean de una sola manera
2) Armar 2 juegos de indices

fecha,codigo y codigo,fecha

Que ocurriria cuando se hagan consultas solo por fecha o solo por codigo ?
No se verian afectadas en rendimiento ?

Por que es tan contradictoria esta opinion con la del otro companero de
arriba ?

Conocen algun articulo que me ayude a aclarar este concepto?

graciasssss...

Hola, articulos hay muchos, podrias ir a www.mug.org.ar y encontraras
algunos.

Te refieres al orden en que se enumeran las columns en el create index o
al
orden en que se especifican en la clausula WHERE de un select ?

Ambos, no es lo mismo un indice Fecha,codigo que luego se consulte asi que
uno Codigo,Fecha

Que ocurriria cuando se hagan consultas solo por fecha o solo por codigo ?
No se verian afectadas en rendimiento ?

Usara los indices (en teoria)

Por que es tan contradictoria esta opinion con la del otro companero de
arriba ?

Que es lo que ves contradictorio?

Salu2
Maxi


"Danilsa" escribió en el mensaje
news:

Hola,
Me interesa muchiiiisimo tambien este tema. He buscado y no encuentro
escritos que ayuden a uno a mentalizar cuales son los mejores indices para
una tabla.

Hola, a ver, el orden es importante en los indices, si haces busquedas
fecha,codigo y luego codigo,fecha podes hacer una cosa

Te refieres al orden en que se enumeran las columns en el create index o
al
orden en que se especifican en la clausula WHERE de un select ?

1) sistematizar para que todas sean de una sola manera
2) Armar 2 juegos de indices

fecha,codigo y codigo,fecha

Que ocurriria cuando se hagan consultas solo por fecha o solo por codigo ?
No se verian afectadas en rendimiento ?

Por que es tan contradictoria esta opinion con la del otro companero de
arriba ?

Conocen algun articulo que me ayude a aclarar este concepto?

graciasssss...

Danilsa,

> Hola, a ver, el orden es importante en los indices, si haces busquedas
> fecha,codigo y luego codigo,fecha podes hacer una cosa
>
Te refieres al orden en que se enumeran las columns en el create index o al
orden en que se especifican en la clausula WHERE de un select ?

Es importante el orden en el que se especifican las columnas cuando creas el
indice.

SQL Server solo guarda solo las estadisticas de la primera columna de un
indice compuesto (indices multi-columnas), por lo que si tu indice es (c1,
c2) sql server podra hacer un seek en el indice si en la clausula "where"
usas c1 = ? and c2 = ? o c1 = ?, pero hara un scan del indice / tabla si solo
aparece c2 = ?.

Ejemplo:

use northwind
go

select
orderid,
customerid,
orderdate
into
dbo.t1
from
dbo.orders
go

create nonclustered index ix_nc_t1_customerid_orderdate on
dbo.t1(customerid, orderdate)
go

set showplan_text on
go

select
orderid,
customerid,
orderdate
from
dbo.t1
where
customerid = 'alfki'
and orderdate = '19970825'
go

select
orderid,
customerid,
orderdate
from
dbo.t1
where
customerid = 'alfki'
go

select
orderid,
customerid,
orderdate
from
dbo.t1
where
orderdate = '19970825'
go

set showplan_text off
go

drop table dbo.t1
go

Otra cosa importante es que si la selectividad en la primera columna es baja
(dado un valor de la columna se seleccionaran muchas filas), entonces cuando
se hace una consulta por c1 = ?, sql server preferira hacer un scan de la
tabla o usar otro indice porque cuando se lee un indice nonclustered (excepto
cuando el indice cubre todas las columnas referenciadas en la sentencia
select) luego hay que leer el indice clustered si este existe o la tabla, o
sea se hace una lectura doble y esto se ve en el plan de ejecucion con el
operador Bookmark Lookup. Fijate en el texto del plan de ejecucion del
ejemplo para que veas que despues de hacer el "index seek" y encontrar la
llave del indice, sql server hace despues un Bookmark Lookup.

Para ver la selectividad puedes usar el comando DBCC SHOW_STATISTICS
(nombre_tabla, nombre indice) y fijate en el resultado del segundo set o
conjunto, especificamente el que dice "All density". La densidad indica el
porciento de valores duplicados bajo las columnas especificadas en "Columns".
LA selectividad y la densidad son inversas, esto significa que menor densidad
mayor selectividad y mayor densidad menor selectividad.

Ejemplo:

select
orderid,
productid,
unitprice,
quantity,
discount
into
dbo.t1
from
dbo.[order details]
go

create nonclustered index ix_nc_t1_productid_orderid on dbo.t1(productid,
orderid)
go

DBCC SHOW_STATISTICS ('dbo.t1', 'ix_nc_t1_productid_orderid')
go

set showplan_text on
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
productid = 59
and orderid = 10387
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
productid = 59
go

set showplan_text off
go

drop table dbo.t1
go

Fijate que la densidad para la columna [productid] es 1.2987013E-2 y para la
combinacion (productid, orderid) es 4.6403712E-4. Esto nos dice que la
selectividad por [productid] es mucho menor (fijate que los numeros estan
expresados en notacion exponencial) que la selectividad por ambas y este caso
si hacemos un filtro por [productid] = ? hara que sql server haga un scan de
la tabla, pero si el filtro es [productid] = ? and [orderid] = ? entonces
hara un seek. que pasa si cambiamos el orden de las columnas en el indice?,
veamos:

drop index dbo.t1.ix_nc_t1_productid_orderid
go

create nonclustered index ix_nc_t1_orderid_productid on dbo.t1(orderid,
productid)
go

DBCC SHOW_STATISTICS ('dbo.t1', 'ix_nc_t1_orderid_productid')
go

set showplan_text on
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
orderid = 10387
and productid = 59
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
orderid = 10387
go

set showplan_text off
go

Ahora la densidad por [orderid] es 1.2048193E-3 y por ([orderid],
[productid]) es 4.6403712E-4. Por lo que podemos ver la densidad por
[orderid] es menor que por [productid] (1.2048193E-3 vs 1.2987013E-2) pero
aun no es menor que la combinacion, pero un buen valor para que sql server
haga un seek en el indice cuando usamos un filtro como [orderid] = 10387.

Lo ultimo ahora es decir que se usa mucho los indices multi-columnas para
mejorar la selectividad (excepto en indices multi-columnas que cubren todas
columnas referenciadas en la sentencia select). Esto se puede evitar si
descompnemos el indice multicolumna en dos indices sencillos (no siempre es
asi), puesto que sql server es lo suficiente inteligente para usar ambos
indices en conjunto.

Ejemplo:

drop index dbo.t1.ix_nc_t1_orderid_productid
go

create nonclustered index ix_nc_t1_orderid on dbo.t1(orderid)
go

create nonclustered index ix_nc_t1_productid on dbo.t1(productid)
go

set showplan_text on
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
orderid = 10387
and productid = 59
go

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
orderid = 10387

select
orderid,
productid,
unitprice,
quantity,
discount
from
dbo.t1
where
productid = 59
go

set showplan_text off
go

drop table dbo.t1
go

fijate que sql server have un seek en el indice cuando el filtro es
[orderid] = ? o [orderid] = ? and [productid] = ?. Hace un scan de la tabla
cuando el filtro es [productid] = ? debido, como habiamos dicho, a que la
densidad por [productis] es muy alta.

Espero y esto te ayude a entender un poco mejor los indices, sobre todo los
nonclustered. Aca te paso unos links donde puedes leer al respecto.

Not All SQL Server Indexes Are Created Equal
http://www.sql-server-performance.c..._equal.asp

en este link, bajo este encabezado " Find SQL Server Performance Tips by
Category
", busca Indexes(General, Clustered, Composite, Covering y
Non-clustered)http://www.sql-server-performance.com/default.asp


AMB

"Danilsa" wrote:

Hola,
Me interesa muchiiiisimo tambien este tema. He buscado y no encuentro
escritos que ayuden a uno a mentalizar cuales son los mejores indices para
una tabla.

> Hola, a ver, el orden es importante en los indices, si haces busquedas
> fecha,codigo y luego codigo,fecha podes hacer una cosa
>
Te refieres al orden en que se enumeran las columns en el create index o al
orden en que se especifican en la clausula WHERE de un select ?

> 1) sistematizar para que todas sean de una sola manera
> 2) Armar 2 juegos de indices
>

fecha,codigo y codigo,fecha

Que ocurriria cuando se hagan consultas solo por fecha o solo por codigo ?
No se verian afectadas en rendimiento ?

Por que es tan contradictoria esta opinion con la del otro companero de
arriba ?

Conocen algun articulo que me ayude a aclarar este concepto?

graciasssss...