OT - Consulta sobre uso de indices o no

jcac,

En el caso de SQL Server, lo importante no es si esa columna es clave
primaria o no, sino si el indice asociado es clustered o nonclustered. Si
es
clustered, SQL Server hara "index seek" en ambas sentencias, pero si es
nonclustered, entonces se comportara similar a lo que describes puesto que
cuando usas un indice nonclustered que no cubre todas la s columnas que
participan en la sentencia, entonces SQL Server busca en el indice
nonclustered y luego debe ir la la tabla o indice clustered a buscar el
resto
de las columnas que participan en la sentencia. Esta operacion se conoce
como
"bookmark lookup", la cual involucra mas lecturas cuando el numero de
filas
que machan la expresion de filtro son muchas. Esa condicion de que dado
una
expresion, machen pocas o muchas filas, se conoce como selectividad.
Mientras
mas selectivo sea un indice nonclustered (menos filas seran seleccionadas
dada una expresion), entonces mayor probabilidad de que este sea usado.


AMB

"jcac" wrote:

Hola lista

Ayer asisti a una presentacion de DB2, en la que indicaron que según su
optimizador, que indican es inteligente, hace las siguientes difenrencias
por ejemplo:

si tenemos una tabla de 1 millon de registros y esta esta indizada por
por
el campo1 que no es pk, entonces mantiene estadisticas del indice, lo que
pienso que el sql server hace lo mismo o si estoy equivocado corrijanme
por
favor.

ahora viendo un caso practico en dicha tabla tenemos distintos datos, en
campo1 exiten datos como 'Blanco', 'Negro', 'Amarilo', etc, teniendo que
estos son repetitivos en muchos casos un color es predominante y en
otros
no, lo que indican es que su optimizador inteligente hace los siguiente:

si el dato que se busca por ejemplo:

select campo1, campo2, campo3 from tabla where campo1 = 'Blanco', pero
este
color tiene digamos 10 registros en la tabla de 1 millon, hara uso del
indice por dicho campo, en el caso:

select campo1, campo2, campo3 from tabla where campo1 = 'Negro', pero
este
color existe dentro de la tabla en 900 mil registros no hara uso del
indice
para hacer la busqueda sino que hara un barrido de toda la tabla debido a
que l mayoria de registros contienen dicha condicion, e indican que
haciendo
de dicha manera es mucho mas rapido que hacer uso del indice.

despues de haberles contado un poco lo que me han dicho lo cual no lo
puedo
comprobar debido a que no cuento con db2, mi duda es como sql server
realiza
las busquedas si la tabla tiene indice por el campo siempre lo usa, o lo
deja de usar???

es casi como una duda de existencialidad

saludos

Hola Alejandro,

Si te daras cuenta en la conversación que tengo con Javier veras que cuando
ejecuto la primera sentencia es decir por el color negro que son pocos hace
uso de Bookmark lookup, claro que esta con seek, pero cuando busco por
blanco que es mas repetitivo el dato este no hace uso del indice de la
columna sino que hace uso de la pk de la tabla.

Me siento medio confundido ya que te entendi que cuando buscara el dato que
hay mas registros haria uso de Bookmark Lookup, pero no lo hizo así, como lo
puedo interpretar???

Saludoy y muchas gracias por el interes

"Alejandro Mesa" escribió en el
mensaje news:
> jcac,
>
> En el caso de SQL Server, lo importante no es si esa columna es clave
> primaria o no, sino si el indice asociado es clustered o nonclustered. Si
> es
> clustered, SQL Server hara "index seek" en ambas sentencias, pero si es
> nonclustered, entonces se comportara similar a lo que describes puesto que
> cuando usas un indice nonclustered que no cubre todas la s columnas que
> participan en la sentencia, entonces SQL Server busca en el indice
> nonclustered y luego debe ir la la tabla o indice clustered a buscar el
> resto
> de las columnas que participan en la sentencia. Esta operacion se conoce
> como
> "bookmark lookup", la cual involucra mas lecturas cuando el numero de
> filas
> que machan la expresion de filtro son muchas. Esa condicion de que dado
> una
> expresion, machen pocas o muchas filas, se conoce como selectividad.
> Mientras
> mas selectivo sea un indice nonclustered (menos filas seran seleccionadas
> dada una expresion), entonces mayor probabilidad de que este sea usado.
>
>
> AMB
>
> "jcac" wrote:
>
>> Hola lista
>>
>> Ayer asisti a una presentacion de DB2, en la que indicaron que según su
>> optimizador, que indican es inteligente, hace las siguientes difenrencias
>> por ejemplo:
>>
>> si tenemos una tabla de 1 millon de registros y esta esta indizada por
>> por
>> el campo1 que no es pk, entonces mantiene estadisticas del indice, lo que
>> pienso que el sql server hace lo mismo o si estoy equivocado corrijanme
>> por
>> favor.
>>
>> ahora viendo un caso practico en dicha tabla tenemos distintos datos, en
>> campo1 exiten datos como 'Blanco', 'Negro', 'Amarilo', etc, teniendo que
>> estos son repetitivos en muchos casos un color es predominante y en
>> otros
>> no, lo que indican es que su optimizador inteligente hace los siguiente:
>>
>> si el dato que se busca por ejemplo:
>>
>> select campo1, campo2, campo3 from tabla where campo1 = 'Blanco', pero
>> este
>> color tiene digamos 10 registros en la tabla de 1 millon, hara uso del
>> indice por dicho campo, en el caso:
>>
>> select campo1, campo2, campo3 from tabla where campo1 = 'Negro', pero
>> este
>> color existe dentro de la tabla en 900 mil registros no hara uso del
>> indice
>> para hacer la busqueda sino que hara un barrido de toda la tabla debido a
>> que l mayoria de registros contienen dicha condicion, e indican que
>> haciendo
>> de dicha manera es mucho mas rapido que hacer uso del indice.
>>
>> despues de haberles contado un poco lo que me han dicho lo cual no lo
>> puedo
>> comprobar debido a que no cuento con db2, mi duda es como sql server
>> realiza
>> las busquedas si la tabla tiene indice por el campo siempre lo usa, o lo
>> deja de usar???
>>
>> es casi como una duda de existencialidad
>>
>> saludos
>>
>>
>>

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Negro'

StmtText
|--Bookmark Lookup(BOOKMARK:([Bmk1000]),
OBJECT:([Documental].[dbo].[prueba]))
|--Index
Seek(OBJECT:([Documental].[dbo].[prueba].[id_prueba_campo2]),
SEEK:([prueba].[campo2]='Negro') ORDERED FORWARD)

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

drop index prueba.id_prueba_campo2
go

y obtuve el mismo resultado que cuando lo tenia
StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

alter table prueba drop constraint PK__prueba__20C1E124
go

y obtuve el siguiente resultado

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Table Scan(OBJECT:([Documental].[dbo].[prueba]),
WHERE:([prueba].[campo2]=[@1]))

Hola Javier,

Muchas gracias por tu paciencia y disposición para ver este tema.

Bueno hice la prueba para ver dicho comportamiento y aqui tengo los
resultados:

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Negro'

StmtText
|--Bookmark Lookup(BOOKMARK:([Bmk1000]),
OBJECT:([Documental].[dbo].[prueba]))
|--Index
Seek(OBJECT:([Documental].[dbo].[prueba].[id_prueba_campo2]),
SEEK:([prueba].[campo2]='Negro') ORDERED FORWARD)


StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

Como veo aqui no usa el indice del campo, pero hace uso del indice de la
tabla, esto no va en contra del rendimiento???

Hice una prueba mas y fue borrar el indice id_prueba_campo2

drop index prueba.id_prueba_campo2
go

y obtuve el mismo resultado que cuando lo tenia
StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

despues he borrado la pk

alter table prueba drop constraint PK__prueba__20C1E124
go

y obtuve el siguiente resultado

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Table Scan(OBJECT:([Documental].[dbo].[prueba]),
WHERE:([prueba].[campo2]=[@1]))

el cual tiene el mismo tiempo de respuesta como si hubiera tenido la pk en
la tabla

si bien lo que estoy buscando es como SQL Server puede diferenciar entre una
cosa u otra, donde puedo encontrar infromación acerca de ello y poder hacer
prueba, tambien considero que son pruebas aisladas pero pienso por lo menos
que daran una idea de lo que podria hacer en una bd en produccion, siguiendo
la misma tematica es donde podria tener informacion de como SQL Server hace
uso de indices o no???? cosa que así se puede comprender mucho mas que es
bueno o malo y cuales son las mejores tecnicas que hay que aplicar.

Espero no aburrirte con esto, es solo que la curiosidad es grande y el hecho
de poder comparar hoy en día es una vemtaja pero para hacerlo hay que
conocer la herramienta que hace y que deja de hacer.

Saludos




"Javier Loria" escribió en el mensaje
news:
> Hola:
> SQL 2000 y SQL 2005. No puedo probar con una 2000 pero debe tener el
> mismo comportamiento 2005.
> Lo que ves en que en tu caso, porque el codigo lo simplificaste
> "demasiado" el segundo indice se quedo como un "indice cubierto" (tiene
> todos los datos de la fila, ya que tienes todos los campos en el indice.
> Veamos que pasaria cuando agregas mas columnas:
> ==> > drop table prueba
>
> create table prueba(campo1 int primary key
> , campo2 varchar(100) NOT NULL
> , campo3 char(100) NOT NULL
> )
> go
> create index id_prueba_campo2 on prueba(campo2)
> go
> declare @i int
> set @i=0
> while @i <= 10000
> begin
> insert into prueba values(@i, 'Blanco', '')
> set @i=@i+1
> continue
> end
> go
> update prueba set campo2 = 'Negro' where campo1 in (1, 10, 100, 1000,
> 10000, 100000, 1000000)
> go
>
> select campo1, campo2, campo3 from prueba where campo2 = 'Negro'
> uso el indice!!!
> select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'
> ==> > Espero se entienda.
> Saludos,
>
>
> Javier Loria
> Costa Rica (MVP)
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda.
>
>
>
> "jcac" wrote in message
> news:
>> Hola Javier,
>>
>> Quizas me podrias indicar desde que versión SQL Server hace uso de
>> esto???, ya que hice una prueba, de este tipo
>>
>> create table prueba(campo1 int primary key, campo2 varchar(100))
>> go
>> create index id_prueba_campo2 on prueba(campo2)
>> go
>> declare @i int
>> set @i=0
>> while @i <= 1000000
>> begin
>> insert into prueba values(@i, 'Blanco')
>> continue
>> end
>> go
>> update prueba set campo2 = 'Negro' where campo1 in (1, 10, 100,. 1000,
>> 10000, 100000, 1000000)
>> go
>>
>> ejecute esta dos consultas
>> select campo1, campo2 from prueba where campo2 = 'Negro'
>> teniendo un tiempo de respuesta muy rapido por menos del segundo,
>> adicionalmente vi el plan de ejecucionm y en definitiva hacia uso del
>> indice, luego lo hice con esta otra
>> select campo1, campo2 from prueba where campo2 = 'Blanco'
>> teniendo un tiempo de respuesta de aproximadamente unos 2 minutos y 28
>> segundos en su plan de ejecución vi que igualmente hacia uso del indice.
>>
>> la versión de SQL Server que utilizo pra realizar esta prueba es la MSDE
>> 2000 con SP4.
>>
>> Saludos
>>
>>
>> "Javier Loria" escribió en el mensaje
>> news:
>>> Hola:
>>> La forma en que se comporta SQL es mas o menos la que describiste.
>>> Si hay muchas filas que cumplen la igualdad no usara el indices y si
>>> hay pocas si.
>>> Por eso es importante hacer uso de indices con columns distintivas.
>>> Saludos,
>>>
>>> Javier Loria
>>> Costa Rica (MVP)
>>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>>> que pueda ser copiado y pegado al Query Analizer.
>>> La version de SQL y Service Pack tambien ayuda.
>>>
>>> "jcac" wrote in message
>>> news:
>>>> Hola lista
>>>>
>>>> Ayer asisti a una presentacion de DB2, en la que indicaron que según su
>>>> optimizador, que indican es inteligente, hace las siguientes
>>>> difenrencias por ejemplo:
>>>>
>>>> si tenemos una tabla de 1 millon de registros y esta esta indizada por
>>>> por el campo1 que no es pk, entonces mantiene estadisticas del indice,
>>>> lo que pienso que el sql server hace lo mismo o si estoy equivocado
>>>> corrijanme por favor.
>>>>
>>>> ahora viendo un caso practico en dicha tabla tenemos distintos datos,
>>>> en campo1 exiten datos como 'Blanco', 'Negro', 'Amarilo', etc, teniendo
>>>> que estos son repetitivos en muchos casos un color es predominante y
>>>> en otros no, lo que indican es que su optimizador inteligente hace los
>>>> siguiente:
>>>>
>>>> si el dato que se busca por ejemplo:
>>>>
>>>> select campo1, campo2, campo3 from tabla where campo1 = 'Blanco', pero
>>>> este color tiene digamos 10 registros en la tabla de 1 millon, hara uso
>>>> del indice por dicho campo, en el caso:
>>>>
>>>> select campo1, campo2, campo3 from tabla where campo1 = 'Negro', pero
>>>> este color existe dentro de la tabla en 900 mil registros no hara uso
>>>> del indice para hacer la busqueda sino que hara un barrido de toda la
>>>> tabla debido a que l mayoria de registros contienen dicha condicion, e
>>>> indican que haciendo de dicha manera es mucho mas rapido que hacer uso
>>>> del indice.
>>>>
>>>> despues de haberles contado un poco lo que me han dicho lo cual no lo
>>>> puedo comprobar debido a que no cuento con db2, mi duda es como sql
>>>> server realiza las busquedas si la tabla tiene indice por el campo
>>>> siempre lo usa, o lo deja de usar???
>>>>
>>>> es casi como una duda de existencialidad
>>>>
>>>> saludos
>>>>
>>>>
>>>
>>
>>
>

despues de haberles contado un poco lo que me han dicho lo cual no lo puedo
comprobar debido a que no cuento con db2, mi duda es como sql server realiza
las busquedas si la tabla tiene indice por el campo siempre lo usa, o lo
deja de usar???

jcac,

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Negro'

StmtText
|--Bookmark Lookup(BOOKMARK:([Bmk1000]),
OBJECT:([Documental].[dbo].[prueba]))
|--Index
Seek(OBJECT:([Documental].[dbo].[prueba].[id_prueba_campo2]),
SEEK:([prueba].[campo2]='Negro') ORDERED FORWARD)

Ya lo explique en otro e-mail. La tabla tiene un indice por [campo2] y
solo
7 filas machan esa expresion (where campo2 = 'Negro'). El indice es
bastante
selectivo (pocas filas para una expresion en concreto) y por lo tanto es
menos costoso buscar en ese indice por [campo2], tomar el valor de la
clave
primaria e ir a buscar el resto de la data en el indice clustered. Esta
accion se llama "bookmark lookup". Exactamente con esta indicado en el
plan
de ejecucion.

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

Demasiadas filas machan esa expresion (where campo2 = 'Blanco'), asi que
en
vez de buscar en el indice nonclustered, por [campo2], y luego ir a buscar
el
resto de la data en el indice clustered (PK__prueba__20C1E124, y por favor
no
confundas indice con clave primaria), SQL Server decide que es menos
costoso
escanear el indice clustered y encontrar la data deseada. Tal como se ve
en
el plan de ejecucion, el indice nonclustered por [campo2] no es de ayuda
alguna.

drop index prueba.id_prueba_campo2
go

y obtuve el mismo resultado que cuando lo tenia
StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

Si borras el indice nonclustered, entonces solamente queda un solo lugar
donde buscar la data y es en el indice clustered (recuerda que los nodos
hojas de un indice clustered son las paginas de data).

alter table prueba drop constraint PK__prueba__20C1E124
go

y obtuve el siguiente resultado

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Table Scan(OBJECT:([Documental].[dbo].[prueba]),
WHERE:([prueba].[campo2]=[@1]))

Bueno, ya no tienes indice alguno, ahora solo queda la tabla sin indice
clustered (heap). Donde mas puede buscarse la data que escaneando la
propia
tabla. Si una tabla tiene indice clustered, entonces este sera usado. Si
la
tabla no tiene indice clustered, entonces la tabla sera usada.


AMB


"jcac" wrote:

Hola Javier,

Muchas gracias por tu paciencia y disposición para ver este tema.

Bueno hice la prueba para ver dicho comportamiento y aqui tengo los
resultados:

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Negro'

StmtText
|--Bookmark Lookup(BOOKMARK:([Bmk1000]),
OBJECT:([Documental].[dbo].[prueba]))
|--Index
Seek(OBJECT:([Documental].[dbo].[prueba].[id_prueba_campo2]),
SEEK:([prueba].[campo2]='Negro') ORDERED FORWARD)


StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

Como veo aqui no usa el indice del campo, pero hace uso del indice de la
tabla, esto no va en contra del rendimiento???

Hice una prueba mas y fue borrar el indice id_prueba_campo2

drop index prueba.id_prueba_campo2
go

y obtuve el mismo resultado que cuando lo tenia
StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Clustered Index
Scan(OBJECT:([Documental].[dbo].[prueba].[PK__prueba__20C1E124]),
WHERE:([prueba].[campo2]='Blanco'))

despues he borrado la pk

alter table prueba drop constraint PK__prueba__20C1E124
go

y obtuve el siguiente resultado

StmtText
select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'

StmtText
|--Table Scan(OBJECT:([Documental].[dbo].[prueba]),
WHERE:([prueba].[campo2]=[@1]))

el cual tiene el mismo tiempo de respuesta como si hubiera tenido la pk
en
la tabla

si bien lo que estoy buscando es como SQL Server puede diferenciar entre
una
cosa u otra, donde puedo encontrar infromación acerca de ello y poder
hacer
prueba, tambien considero que son pruebas aisladas pero pienso por lo
menos
que daran una idea de lo que podria hacer en una bd en produccion,
siguiendo
la misma tematica es donde podria tener informacion de como SQL Server
hace
uso de indices o no???? cosa que así se puede comprender mucho mas que es
bueno o malo y cuales son las mejores tecnicas que hay que aplicar.

Espero no aburrirte con esto, es solo que la curiosidad es grande y el
hecho
de poder comparar hoy en día es una vemtaja pero para hacerlo hay que
conocer la herramienta que hace y que deja de hacer.

Saludos




"Javier Loria" escribió en el mensaje
news:
> Hola:
> SQL 2000 y SQL 2005. No puedo probar con una 2000 pero debe tener el
> mismo comportamiento 2005.
> Lo que ves en que en tu caso, porque el codigo lo simplificaste
> "demasiado" el segundo indice se quedo como un "indice cubierto"
> (tiene
> todos los datos de la fila, ya que tienes todos los campos en el
> indice.
> Veamos que pasaria cuando agregas mas columnas:
> ==>> > drop table prueba
>
> create table prueba(campo1 int primary key
> , campo2 varchar(100) NOT NULL
> , campo3 char(100) NOT NULL
> )
> go
> create index id_prueba_campo2 on prueba(campo2)
> go
> declare @i int
> set @i=0
> while @i <= 10000
> begin
> insert into prueba values(@i, 'Blanco', '')
> set @i=@i+1
> continue
> end
> go
> update prueba set campo2 = 'Negro' where campo1 in (1, 10, 100, 1000,
> 10000, 100000, 1000000)
> go
>
> select campo1, campo2, campo3 from prueba where campo2 = 'Negro'
> uso el indice!!!
> select campo1, campo2, campo3 from prueba where campo2 = 'Blanco'
> ==>> > Espero se entienda.
> Saludos,
>
>
> Javier Loria
> Costa Rica (MVP)
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda.
>
>
>
> "jcac" wrote in message
> news:
>> Hola Javier,
>>
>> Quizas me podrias indicar desde que versión SQL Server hace uso de
>> esto???, ya que hice una prueba, de este tipo
>>
>> create table prueba(campo1 int primary key, campo2 varchar(100))
>> go
>> create index id_prueba_campo2 on prueba(campo2)
>> go
>> declare @i int
>> set @i=0
>> while @i <= 1000000
>> begin
>> insert into prueba values(@i, 'Blanco')
>> continue
>> end
>> go
>> update prueba set campo2 = 'Negro' where campo1 in (1, 10, 100,. 1000,
>> 10000, 100000, 1000000)
>> go
>>
>> ejecute esta dos consultas
>> select campo1, campo2 from prueba where campo2 = 'Negro'
>> teniendo un tiempo de respuesta muy rapido por menos del segundo,
>> adicionalmente vi el plan de ejecucionm y en definitiva hacia uso del
>> indice, luego lo hice con esta otra
>> select campo1, campo2 from prueba where campo2 = 'Blanco'
>> teniendo un tiempo de respuesta de aproximadamente unos 2 minutos y 28
>> segundos en su plan de ejecución vi que igualmente hacia uso del
>> indice.
>>
>> la versión de SQL Server que utilizo pra realizar esta prueba es la
>> MSDE
>> 2000 con SP4.
>>
>> Saludos
>>
>>
>> "Javier Loria" escribió en el mensaje
>> news:
>>> Hola:
>>> La forma en que se comporta SQL es mas o menos la que describiste.
>>> Si hay muchas filas que cumplen la igualdad no usara el indices y
>>> si
>>> hay pocas si.
>>> Por eso es importante hacer uso de indices con columns
>>> distintivas.
>>> Saludos,
>>>
>>> Javier Loria
>>> Costa Rica (MVP)
>>> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
>>> que pueda ser copiado y pegado al Query Analizer.
>>> La version de SQL y Service Pack tambien ayuda.
>>>
>>> "jcac" wrote in message
>>> news:
>>>> Hola lista
>>>>
>>>> Ayer asisti a una presentacion de DB2, en la que indicaron que según
>>>> su
>>>> optimizador, que indican es inteligente, hace las siguientes
>>>> difenrencias por ejemplo:
>>>>
>>>> si tenemos una tabla de 1 millon de registros y esta esta indizada
>>>> por
>>>> por el campo1 que no es pk, entonces mantiene estadisticas del
>>>> indice,
>>>> lo que pienso que el sql server hace lo mismo o si estoy equivocado
>>>> corrijanme por favor.
>>>>
>>>> ahora viendo un caso practico en dicha tabla tenemos distintos
>>>> datos,
>>>> en campo1 exiten datos como 'Blanco', 'Negro', 'Amarilo', etc,
>>>> teniendo
>>>> que estos son repetitivos en muchos casos un color es predominante
>>>> y
>>>> en otros no, lo que indican es que su optimizador inteligente hace
>>>> los
>>>> siguiente:
>>>>
>>>> si el dato que se busca por ejemplo:
>>>>
>>>> select campo1, campo2, campo3 from tabla where campo1 = 'Blanco',
>>>> pero
>>>> este color tiene digamos 10 registros en la tabla de 1 millon, hara
>>>> uso
>>>> del indice por dicho campo, en el caso:
>>>>
>>>> select campo1, campo2, campo3 from tabla where campo1 = 'Negro',
>>>> pero
>>>> este color existe dentro de la tabla en 900 mil registros no hara
>>>> uso
>>>> del indice para hacer la busqueda sino que hara un barrido de toda
>>>> la
>>>> tabla debido a que l mayoria de registros contienen dicha condicion,
>>>> e
>>>> indican que haciendo de dicha manera es mucho mas rapido que hacer
>>>> uso
>>>> del indice.
>>>>
>>>> despues de haberles contado un poco lo que me han dicho lo cual no
>>>> lo
>>>> puedo comprobar debido a que no cuento con db2, mi duda es como sql
>>>> server realiza las busquedas si la tabla tiene indice por el campo
>>>> siempre lo usa, o lo deja de usar???
>>>>
>>>> es casi como una duda de existencialidad
>>>>
>>>> saludos
>>>>
>>>>
>>>
>>
>>
>