La regla de la izquierda -- Indices

No, no hace falta que la consulta incluya todas las columnas. SQL Server
puede llegar a usar el índice en el segundo ejemplo que pones (SELECT ...
WHERE ID=X AND ADRESS=Y), aunque evidentemente sería más útil si incluyes la
segunda o directamente todas las columnas.

Digo puede que lo use porque depende de la selectividad de los valores que
contenga esa columna y del valor por el que filtres.

Puedes ver ese comportamiento si incluyes el plan de ejecución de la consulta.

Un saludo
-
www.navento.com
Servicios de Localización GPS


"Normanmp" wrote:

La regla de la izquierda -> Sé que esto funciona para MYSQL tengo dudas si es
tambien valido para SQL server, por lo que megustaria que me lo confirmarais:

Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT ...
WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría un
SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya una
columna parte del index sin incluir además las columnas a su izquierda, no
usará el indice.

Por tanto en nuestro ejemplo solo sacarian provecho del indice las consultas
SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND NAME
= y AND ADRESS = Z

Gracias

La regla de la izda es aplicable a SQL Server. Sin embargo ...

Supongamos que el índice es no agrupado.

La consulta:

SELECT *
FROM Tabla
WHERE ID = x

Sólo usará el índice si el número estimado de filas devueltos por la
consulta es menor que aproximadamente el 0,5% de las filas de la tabla.

La consulta

SELECT *
FROM Tabla
WHERE ID = x AND (<lo que sea>)

Sólo usará el índice si el número estimado de filas devueltos por la
consulta es menor que aproximadamente el 0,5% de las filas de la tabla.

La consulta:

SELECT ID, NAME, ADDRESS
FROM Tabla
WHERE ID = x

Siempre usará el índice.

La consulta:

SELECT COUNT(*)
FROM Tabla
WHERE ID = x

Siempre usará el índice.



"Normanmp" escribió en el mensaje de
noticias news:

La regla de la izquierda -> Sé que esto funciona para MYSQL tengo dudas si
es
tambien valido para SQL server, por lo que megustaria que me lo
confirmarais:

Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT ...
WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría un
SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya una
columna parte del index sin incluir además las columnas a su izquierda, no
usará el indice.

Por tanto en nuestro ejemplo solo sacarian provecho del indice las
consultas
SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND
NAME
= y AND ADRESS = Z

Gracias

Normanmp,

SQL Server mantiene estadisticas de distribución de los valores presentes en
las columnas que forman parte de un indice, pero el histograma de
distribucion se mantiene solo para la columna lider o primera de izquierda a
derecha en la definicion de la llave. Entre otras estadisticas, tambien se
tiene un valor llamado "All density" de la combinacion de columnas de
izquirda a derecha, incluyendo tambien las columnas de el indice clustered en
caso de existir.

create clustered index _t_c1_nu_c_ix
on dbo.t(c1)

create nonclustered index t_c2_c3_nu_nc_ix
on dbo.t(c2, c3)

All Density (para el indice nonclustered)

c2 -- x1
c2, c3 -- x2
c2, c3, c1 -- x3

Las estadisticas de distribucion, se utilizan principalmente para estimar el
numero de filas que pueden machar cierto predicado, y como el histograma solo
se mantiene para la columna lider de la clave, entonces esta se debe usar en
el predicado para poder tener acceso a este.

Basado en el indice nonclustered anterior, tenemos acceso a su histograma si
usamos:

...
where c2 = ?

...
where c2 = ? and c3 = ?

no asi para:

...
where c3 = ?

en cuyo caso puede usarse el valor de "All density" ligado a esa columna,
pero este valor no es tan exacto como el de la distribucion de el histograma.

Te recomiendo la lectura de el comando DBCC SHOW_STATISTICS en los BOL.

Aqui te paso un par de link que te pudieran ser de ayuda. Estos articulos
estan basado en SS 2000, pero la mayoria de lo que se explica aplica a 2005.

Estadísticas de distribución en SQL Server 2000 (I)
http://www.helpdna.net/sqlserver_20...ndices.htm

Estadísticas de Distribución en SQL Server 2000 (2
http://www.configuracionesintegrale...articulo34


AMB


"Normanmp" wrote:

La regla de la izquierda -> Sé que esto funciona para MYSQL tengo dudas si es
tambien valido para SQL server, por lo que megustaria que me lo confirmarais:

Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT ...
WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría un
SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya una
columna parte del index sin incluir además las columnas a su izquierda, no
usará el indice.

Por tanto en nuestro ejemplo solo sacarian provecho del indice las consultas
SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND NAME
= y AND ADRESS = Z

Gracias

Corrección:

no asi para:

...
where c3 = ?

en cuyo caso puede usarse el valor de "All density" ligado a esa columna,
pero este valor no es tan exacto como el de la distribucion de el histograma.

Me contradije enesta declaracion, pues no existe valor de "All Density" solo
para esa columna. La combinacion es progresiva empezando desde la izquierda y
debe incluir las columnas previas. Por eso no es posible estimar el numero de
filas que pueden machar la expresion:

...
where c3 = ?

y por lo tanto se debera hacer un scan de la tabla o el indice clustered en
caso de este existir.


AMB


"Alejandro Mesa" wrote:

Normanmp,

SQL Server mantiene estadisticas de distribución de los valores presentes en
las columnas que forman parte de un indice, pero el histograma de
distribucion se mantiene solo para la columna lider o primera de izquierda a
derecha en la definicion de la llave. Entre otras estadisticas, tambien se
tiene un valor llamado "All density" de la combinacion de columnas de
izquirda a derecha, incluyendo tambien las columnas de el indice clustered en
caso de existir.

create clustered index _t_c1_nu_c_ix
on dbo.t(c1)

create nonclustered index t_c2_c3_nu_nc_ix
on dbo.t(c2, c3)

All Density (para el indice nonclustered)

c2 -- x1
c2, c3 -- x2
c2, c3, c1 -- x3

Las estadisticas de distribucion, se utilizan principalmente para estimar el
numero de filas que pueden machar cierto predicado, y como el histograma solo
se mantiene para la columna lider de la clave, entonces esta se debe usar en
el predicado para poder tener acceso a este.

Basado en el indice nonclustered anterior, tenemos acceso a su histograma si
usamos:

...
where c2 = ?

...
where c2 = ? and c3 = ?

no asi para:

...
where c3 = ?

en cuyo caso puede usarse el valor de "All density" ligado a esa columna,
pero este valor no es tan exacto como el de la distribucion de el histograma.

Te recomiendo la lectura de el comando DBCC SHOW_STATISTICS en los BOL.

Aqui te paso un par de link que te pudieran ser de ayuda. Estos articulos
estan basado en SS 2000, pero la mayoria de lo que se explica aplica a 2005.

Estadísticas de distribución en SQL Server 2000 (I)
http://www.helpdna.net/sqlserver_20...ndices.htm

Estadísticas de Distribución en SQL Server 2000 (2)
http://www.configuracionesintegrale...articulo34


AMB


"Normanmp" wrote:

> La regla de la izquierda -> Sé que esto funciona para MYSQL tengo dudas si es
> tambien valido para SQL server, por lo que megustaria que me lo confirmarais:
>
> Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT ...
> WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría un
> SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya una
> columna parte del index sin incluir además las columnas a su izquierda, no
> usará el indice.
>
> Por tanto en nuestro ejemplo solo sacarian provecho del indice las consultas
> SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND NAME
> = y AND ADRESS = Z
>
> Gracias
>

Alejandro, si la condicion sobre esa columna (c3 = ?) es muy convergente,
supongamos en extremo 1 registro, y si la cantidad de paginas de la tabla es
grande en comparacion al indice, va a hacer un index scan y luego el lookup
ya que eso es menos costoso que el scan de la table. Si la cantidad de
registros crece, va a llegar un punto que el costo que produce la estructura
de los indices y la aleatorizacion de accesos del nonclustered index que va
a preferir un acceso mediante un table scan.


Saludos


Ing. Jose Mariano Alvarez
SQLTotal Consulting

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

Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase. Por
favor tratar de indicar la versión de SQL y Service Pack. La inclusión de
(CREATE, INSERTS, etc.) para poder reproducir el problema también ayuda.










"Alejandro Mesa" wrote in message
news:

Corrección:

no asi para:

...
where c3 = ?

en cuyo caso puede usarse el valor de "All density" ligado a esa columna,
pero este valor no es tan exacto como el de la distribucion de el
histograma.

Me contradije enesta declaracion, pues no existe valor de "All Density"
solo
para esa columna. La combinacion es progresiva empezando desde la
izquierda y
debe incluir las columnas previas. Por eso no es posible estimar el numero
de
filas que pueden machar la expresion:

...
where c3 = ?

y por lo tanto se debera hacer un scan de la tabla o el indice clustered
en
caso de este existir.


AMB


"Alejandro Mesa" wrote:

Normanmp,

SQL Server mantiene estadisticas de distribución de los valores presentes
en
las columnas que forman parte de un indice, pero el histograma de
distribucion se mantiene solo para la columna lider o primera de
izquierda a
derecha en la definicion de la llave. Entre otras estadisticas, tambien
se
tiene un valor llamado "All density" de la combinacion de columnas de
izquirda a derecha, incluyendo tambien las columnas de el indice
clustered en
caso de existir.

create clustered index _t_c1_nu_c_ix
on dbo.t(c1)

create nonclustered index t_c2_c3_nu_nc_ix
on dbo.t(c2, c3)

All Density (para el indice nonclustered)

c2 -- x1
c2, c3 -- x2
c2, c3, c1 -- x3

Las estadisticas de distribucion, se utilizan principalmente para estimar
el
numero de filas que pueden machar cierto predicado, y como el histograma
solo
se mantiene para la columna lider de la clave, entonces esta se debe usar
en
el predicado para poder tener acceso a este.

Basado en el indice nonclustered anterior, tenemos acceso a su histograma
si
usamos:

...
where c2 = ?

...
where c2 = ? and c3 = ?

no asi para:

...
where c3 = ?

en cuyo caso puede usarse el valor de "All density" ligado a esa columna,
pero este valor no es tan exacto como el de la distribucion de el
histograma.

Te recomiendo la lectura de el comando DBCC SHOW_STATISTICS en los BOL.

Aqui te paso un par de link que te pudieran ser de ayuda. Estos articulos
estan basado en SS 2000, pero la mayoria de lo que se explica aplica a
2005.

Estadísticas de distribución en SQL Server 2000 (I)
http://www.helpdna.net/sqlserver_20...ndices.htm

Estadísticas de Distribución en SQL Server 2000 (2)
http://www.configuracionesintegrale...articulo34


AMB


"Normanmp" wrote:

> La regla de la izquierda -> Sé que esto funciona para MYSQL tengo dudas
> si es
> tambien valido para SQL server, por lo que megustaria que me lo
> confirmarais:
>
> Supongamos un INDEX usuario (id, name, adress), y una cláusula SELECT
> ...
> WHERE NAME = x. Este Select no aprovechará el índice. Tampoco lo haría
> un
> SELECT ... WHERE ID =X AND ADRESS = Y. Cualquier consulta que incluya
> una
> columna parte del index sin incluir además las columnas a su izquierda,
> no
> usará el indice.
>
> Por tanto en nuestro ejemplo solo sacarian provecho del indice las
> consultas
> SELECT ... WHERE ID = x, o WHERE ID = X AND NAME = y o WHERE ID = x AND
> NAME
> = y AND ADRESS = Z
>
> Gracias
>