Mejora una consulta Indexando campos fisicamente??

[nefy]

Hola en otro club q estoy adscrito surgio este tema: "Una consulta se ejecutara mas rapido si los campos q incluyas en el Order By de un select estan indexados". Yo la verdad no lo creo en lo personal (no tengo documentacion para respaldar esta forma de pensar), pero es q he buscado y no he encontrado un lugar en el q me deje convencido de lo contrario, es decir, q cuando un campo esta indexado si se utliza en una consulta, esta se generara mas rapido.

Me citaron la siguiente informacion:

http://www.latiumsoftware.com/es/pascal/0046.php

en el apartado "Use índices en columnas de relación". Ya lo lei pero no me convencio en lo absoluto. Asi q consulto con ustedes.
¿Es recomendable indexar una tabla para optimizar una consulta?(Sin contar q no es recomendable tener muchos indices).

Salu2.

[delphi.com.ar]

Empezado por nefy

Hola en otro club q estoy adscrito surgio este tema: "Una consulta se ejecutara mas rapido si los campos q incluyas en el Order By de un select estan indexados". Yo la verdad no lo creo en lo personal (no tengo documentacion para respaldar esta forma de pensar), pero es q he buscado y no he encontrado un lugar en el q me deje convencido de lo contrario, es decir, q cuando un campo esta indexado si se utliza en una consulta, esta se generara mas rapido.

En Oracle, si no utilizas un flitro previo, y ordenas por un campo no indexado, el proceso es mucho mas lento, pues tiene que armar todo el set de resultados, ordenarlo en su totalidad y luego enviárselo al cliente. Si el campo esta indexado, simplemente retorna la primer página de resultados utilizando el índicie, luego entregará el resto de las páginas cuando se vaya necesitando.
No se que motor utilizas, pero te recomiendo ver el plan de ejecución para corroborar esto.

Saludos!

[nefy]

Pues apenas tengo unos meses con Firebird 1.5 y aun no he leido toda la documentacion asi q no lo se, pero pues tocara investigar. Sin embargo, me imagino q mas o menos tambien iran por ahi los tiros.

Salu2.

[jachguate]

En primer lugar, aclarar que los indices no son tan útiles para optimizar enfocado a la clausula Order by, como pueden serlo para la clausula where.

Por otro lado, la mejora en el rendimiento en cualquier caso, dependerá de la capacidad del optimizador del motor. Me he topado con consultas bastante complejas que en Oracle tardan una nada, y en otros motores, con la misma estructura, tardan mucho mas. Asi que cuando se diseña la estructura, y cuando se escribe la consulta, si se quiere realmente optimizar, hay que tener en cuenta el motor y sus características.

En casi cualquier caso (firebird, mySQL, oracle, etc), no dudo que una consulta del tipo:

Código SQL [-]
Select *
  from tabla
 where campo_unico = valor

Con una tabla, con digamos 500,000 registros...

pues si tenes un índice sobre campo_unico, tardará solo una fracción de segundo, pero si no tenes índice, podria ser hasta un minuto (ya dependerá del hardware).

En un caso hipotético de un motor de búsqueda, donde fácilmente tenes una consulta que te devuelve 100,000 registros (de una tabla con millones), digamos:

Código SQL [-]
Select titulo, url, rango
  from paginas_indexadas
 where (texto_pagina like '%delphi%en%espa_ol%'
            or texto_pagina like '%espa_ol en delphi%')
   and (texto_pagina not like '%kilyx%')
   and not (url starts with 'www.borland')
 order by rango desc, fecha_indexacion desc

Normalmente mostrarás solo un puñado de los primeros resultados. Digamos 25. (La forma de obtener solo los primeros 25 varia de acuerdo al motor de BD por eso no lo incluyo).

Bien, si el optimizador no es capaz de generar un plan que le permita ubicar los registros correctos y de una vez le devuelva los datos ordenados... pues habrá que esperar a tener los 100,000 resultados, ordernarlos y devolver los primeros 25!!. Eso podria demorar mucho tiempo para un navegante que está acostumbrado a la velocidad de google..

En cambio, si pueden venir ordenados de una vez, bastará con que el motor obtenga los primeros 25 y los devuelva. Podria ser un tiempo considerable, pero mucho menor que el anterior.

He puesto un caso exagerado, pero real para algunos (con suerte, creo).

Hasta luego.

[marcoszorrilla]

Recuerdo haber hecho algunas pruebas hace ya tiempo con Paradox y según cronómetro, no hacía uso de los índices puesto que ataque una tabla con SQL utilizando Order By y Where, y tardaba exactamente lo mismo con índices que sin ellos, por lo tanto, dependerá del motor que se esté utilizando y la inteligencia de que le hayan dotado.

Un Saludo.

[delphi.com.ar]

Empezado por marcoszorrilla

...dependerá del motor que se esté utilizando...

Por eso aclaré que lo que comentaba era en Oracle

[roman]

Empezado por marcoszorrilla

Recuerdo haber hecho algunas pruebas hace ya tiempo con Paradox y según cronómetro, no hacía uso de los índices

Así es. Al parecer Paradox (o por lo menos el bde) usa índices sólo para relacionar tablas con componentes TTable. Razón por la cual en Paradox, contrario a cualquier servidor real, es mucho mejor evitar, en la medida de lo posible el uso de SQL.

// Saludos

[Pablo Carlos]

Yo uso paradox y sql (roman tiene razon en cuanto a los indices, estos no interfieren en el sql) pero no comparto el evitar sql con paradox... todas las consultas que hago en mi prg son sql con los famosos componentes query hasta ahora no he tenido inconvenientes de demora... solo digo hasta ahora