OT - Consulta sobre uso de indices o no

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

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 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

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'
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

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