consulta sobre indices

Hola
disculpa, gracias por la paciencia

esta como CLUSTERED

¿?
Luis


"Alejandro Mesa" escribió en el
mensaje de noticias
news:

Luis,

Hombre, sera que no me hago entender bien.

y hay un indice unico

Que tipo de indice, clustered o nonclustered?


AMB


"Luis Mata" wrote:

Ok

el campo codigo es de 11 caracteres
y hay un indice unico pero aun asi al consultar un solo codigo es un poco
lento, hablo de 250000 registros
"Alejandro Mesa" escribió en el
mensaje de noticias
news:
> Luis,
>
> Pudieras de una vez darnos toda la info sobre esa tabla?
>
> Al parecer pudieras crear un indice unico y clustered por esa columna.
> Debes
> tener en cuenta la longitud de la columna [codigo] pues una clave muy
> ancha
> en el indice clustered no es recomendable.
>
>
> AMB
>
>
> "Luis Mata" wrote:
>
>> - es unico
>> - otras columnas(nombre, apellido, direccion, telefono,..)
>> - clave: codigo
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje de noticias
>> news:
>> > Luis Mata,
>> >
>> > Depende de algunos factores que no has mencionado en tu mensaje.
>> >
>> > - Los valores en la columna [codigo] son unicos o no?
>> > - Que otras columnas son referenciadas en esa sentencia?
>> > - Existe algun indice en esa tabla?
>> > - Existe alguna clave primaria?
>> >
>> > AMB
>> >
>> >
>> > "Luis Mata" wrote:
>> >
>> >> Hola
>> >> tengo una tabla de 250,000 registros creo una consulta de:
>> >>
>> >> SELECT campos FROM CLIENTE where codigo = '123456'
>> >>
>> >> que diferencia de tiempo habria entre una tabla con campo CODIGO
>> >> indexado
>> >> y
>> >> no indexado?
>> >> Alguien lo ha testeado?
>> >>
>> >> disculpen la ignorancia
>> >>
>> >> Luis
>> >>
>> >>
>> >>
>>
>>

Luis,

Ese indice satisface perfectamente la sentencia que usas.

Dices que es lento, por casualidad has chequeado fragmentacion de ese indice?

Chequea la funcion sys.dm_db_index_physical_stats en los BOL.


AMB


"Luis Mata" wrote:

Hola
disculpa, gracias por la paciencia

esta como CLUSTERED

¿?
Luis


"Alejandro Mesa" escribió en el
mensaje de noticias
news:
> Luis,
>
> Hombre, sera que no me hago entender bien.
>
>> y hay un indice unico
>
> Que tipo de indice, clustered o nonclustered?
>
>
> AMB
>
>
> "Luis Mata" wrote:
>
>> Ok
>>
>> el campo codigo es de 11 caracteres
>> y hay un indice unico pero aun asi al consultar un solo codigo es un poco
>> lento, hablo de 250000 registros
>> "Alejandro Mesa" escribió en el
>> mensaje de noticias
>> news:
>> > Luis,
>> >
>> > Pudieras de una vez darnos toda la info sobre esa tabla?
>> >
>> > Al parecer pudieras crear un indice unico y clustered por esa columna.
>> > Debes
>> > tener en cuenta la longitud de la columna [codigo] pues una clave muy
>> > ancha
>> > en el indice clustered no es recomendable.
>> >
>> >
>> > AMB
>> >
>> >
>> > "Luis Mata" wrote:
>> >
>> >> - es unico
>> >> - otras columnas(nombre, apellido, direccion, telefono,..)
>> >> - clave: codigo
>> >>
>> >>
>> >> "Alejandro Mesa" escribió en
>> >> el
>> >> mensaje de noticias
>> >> news:
>> >> > Luis Mata,
>> >> >
>> >> > Depende de algunos factores que no has mencionado en tu mensaje.
>> >> >
>> >> > - Los valores en la columna [codigo] son unicos o no?
>> >> > - Que otras columnas son referenciadas en esa sentencia?
>> >> > - Existe algun indice en esa tabla?
>> >> > - Existe alguna clave primaria?
>> >> >
>> >> > AMB
>> >> >
>> >> >
>> >> > "Luis Mata" wrote:
>> >> >
>> >> >> Hola
>> >> >> tengo una tabla de 250,000 registros creo una consulta de:
>> >> >>
>> >> >> SELECT campos FROM CLIENTE where codigo = '123456'
>> >> >>
>> >> >> que diferencia de tiempo habria entre una tabla con campo CODIGO
>> >> >> indexado
>> >> >> y
>> >> >> no indexado?
>> >> >> Alguien lo ha testeado?
>> >> >>
>> >> >> disculpen la ignorancia
>> >> >>
>> >> >> Luis
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>

columna. Debes
tener en cuenta la longitud de la columna [codigo] pues una clave muy
ancha
en el indice clustered no es recomendable.

Cuando aproximadamente se puede considerar muy ancha una clave para un
indice clustered?

Pedro,

No existe una formula en especial para eso, se deja a la discrecion de el
diseniador / programador / dba, etc.

Lo que si te puedo decir es que mientras mas estrecha sea, mejor
funcionalidad tendra en cuanto a espacio consumido por los indices
nonclustered. Mientras mas pequenia sea la clave de el indice clustered, mas
filas se podran almacenar en el indice nonclustered por cada pagina, y por
tanto menos operaciones de IO se necesitaran.

SQL Server usa la clave de el indice clustered en cada indice nonclustered,
para que se pueda llevar a cabo la operacion de "key lookup", operacion que
se lleva a cabo cuando SQL Server usa un indice nonclustered para encontrar
las filas que cumplen la condicion, pero el indice no contiene todas las
columnas referenciadas y por lo tanto se debe ir a la tabla o al indice
clustered a buscar el resto de la data que se necesita.

Este tema es un poquito extenso para exponerlo en su totalidad en un mensaje
como este, pero tratare de ser conciso.

Si un indice nonclustered no contiene todas las columnas referenciadas por
la sentencia select, puede ser en el JOIN, en la clausula WHERE, HAVING, etc,
entonces SQL Server debe traer el resto de esa data desde la tabla, o desde
el indice clustered. Como SQL Server sabe exactamente cual es la fila que
corresponde con cierta fila de el indice nonclustered?.

1 - Todo indice clustered es unico, de forma que SQL Server pueda
identificar cada fila unicamente. Si la combinacion de columnas que forman la
clave de el indice clustered no es unica, o sea, que no identifica unicamente
las filas en el indice, SQL Server adiciona, por detras de el telon, un valor
entero a las filas duplicadas para que esa clave sea unica. Esto no pasa si
la combinacion de columnas sirve para identificar unicamente las filas, como
pasa con una restriccion de clave primaria, donde SQL Server usa un indice
clustered unico para implementar esa restriccion.

2 - SQL Server adiciona la clave de el indice clustered, en los nodos hojas
de cada indice nonclustered, y si el indice nonclustered no es unico,
entonces adiciona la clave de el indice clustered a la clave de el indice
nonclustered para hacerla unica.

Todo esto puedes leerlos en los BOL y en los sgtes libros.

Inside Microsoft SQL Server(TM) 2005: The Storage Engin
http://www.amazon.com/Inside-Micros...y_b_text_b

Inside Microsoft® SQL Server(TM) 2005: Query Tuning and Optimizatio
http://www.amazon.com/s/ref=nb_ss_g...aney&x&y

Microsoft SQL Server 2005 Unleashe
http://www.amazon.com/Microsoft-SQL...ks&qid19408182&sr=1-1

Aca tienes una breve explicacion dada por Kalen Delaney.

Geek City: Nonclustered Index Key
http://sqlblog.com/blogs/kalen_dela...-keys.aspx


AMB


"Pedro" wrote:

>columna. Debes
> tener en cuenta la longitud de la columna [codigo] pues una clave muy
> ancha
> en el indice clustered no es recomendable.

Cuando aproximadamente se puede considerar muy ancha una clave para un
indice clustered?

Muchas gracias por esa gran explicacion que me has dado.



"Alejandro Mesa" escribió en el
mensaje news:

Pedro,

No existe una formula en especial para eso, se deja a la discrecion de el
diseniador / programador / dba, etc.

Lo que si te puedo decir es que mientras mas estrecha sea, mejor
funcionalidad tendra en cuanto a espacio consumido por los indices
nonclustered. Mientras mas pequenia sea la clave de el indice clustered,
mas
filas se podran almacenar en el indice nonclustered por cada pagina, y por
tanto menos operaciones de IO se necesitaran.

SQL Server usa la clave de el indice clustered en cada indice
nonclustered,
para que se pueda llevar a cabo la operacion de "key lookup", operacion
que
se lleva a cabo cuando SQL Server usa un indice nonclustered para
encontrar
las filas que cumplen la condicion, pero el indice no contiene todas las
columnas referenciadas y por lo tanto se debe ir a la tabla o al indice
clustered a buscar el resto de la data que se necesita.

Este tema es un poquito extenso para exponerlo en su totalidad en un
mensaje
como este, pero tratare de ser conciso.

Si un indice nonclustered no contiene todas las columnas referenciadas por
la sentencia select, puede ser en el JOIN, en la clausula WHERE, HAVING,
etc,
entonces SQL Server debe traer el resto de esa data desde la tabla, o
desde
el indice clustered. Como SQL Server sabe exactamente cual es la fila que
corresponde con cierta fila de el indice nonclustered?.

1 - Todo indice clustered es unico, de forma que SQL Server pueda
identificar cada fila unicamente. Si la combinacion de columnas que forman
la
clave de el indice clustered no es unica, o sea, que no identifica
unicamente
las filas en el indice, SQL Server adiciona, por detras de el telon, un
valor
entero a las filas duplicadas para que esa clave sea unica. Esto no pasa
si
la combinacion de columnas sirve para identificar unicamente las filas,
como
pasa con una restriccion de clave primaria, donde SQL Server usa un indice
clustered unico para implementar esa restriccion.

2 - SQL Server adiciona la clave de el indice clustered, en los nodos
hojas
de cada indice nonclustered, y si el indice nonclustered no es unico,
entonces adiciona la clave de el indice clustered a la clave de el indice
nonclustered para hacerla unica.

Todo esto puedes leerlos en los BOL y en los sgtes libros.

Inside Microsoft SQL Server(TM) 2005: The Storage Engine
http://www.amazon.com/Inside-Micros...y_b_text_b

Inside Microsoft® SQL Server(TM) 2005: Query Tuning and Optimization
http://www.amazon.com/s/ref=nb_ss_g...aney&x&y

Microsoft SQL Server 2005 Unleashed
http://www.amazon.com/Microsoft-SQL...ks&qid19408182&sr=1-1

Aca tienes una breve explicacion dada por Kalen Delaney.

Geek City: Nonclustered Index Keys
http://sqlblog.com/blogs/kalen_dela...-keys.aspx


AMB


"Pedro" wrote:

>columna. Debes
> tener en cuenta la longitud de la columna [codigo] pues una clave muy
> ancha
> en el indice clustered no es recomendable.

Cuando aproximadamente se puede considerar muy ancha una clave para un
indice clustered?