Ya teneis que estar cansados de mis despotriques de mi trabajo, pero siempre suelen ser por mis compañeros (ayer de hecho me tuve que tragar una bronca y disculparme cuando no era cosa mía, vine cabreada). Pero es que el propio trabajo a veces me hace tirarme de los pelos, y esta vez tengo un buen ejemplo.
No me voy a mojar mucho detallando porque sería fácil que encontraran este blog (suficiente es que se vea mi careto por alguna parte), así que diré que programando tengo que hacer selects, dentro de un lenguaje, y que éstas se traducen por un driver a la sintaxis de Oracle. Es una compañía grande, así que me encuentro con tablas de millones de registros fácilmente, alguna hasta con más de 100 campos, de modo que hay que procurar hacer las cosas de forma óptima.
Hoy, pues nada, haciendo una consulta sobre una tabla de casi 1 millón de registros. Como no hay índice para la consulta que tengo que hacer, sugiero la idea, y se me acepta. Tan chula yo, voy y escribo más o menos esto:
select tablita.*
from tablita
where tablita.indice15=(tal,pascual)
and blablabla…
indice15 para mi siempre ha sido que utilizo el índice 15, es decir el que acababa de crear. Lo presento, y me dicen que eso no es óptimo, que no estoy utilizando el índice ¿WTF? Vale, por una parte entiendo que en el fondo, .indice15 en realidad es un campo combinado, un campo oculto de la tabla que es la concatenación de tal y de pascual. Pero si así no usa el índice, ¿entonces qué hace? Pues por defecto Oracle hará uso del índice que le digan de las estadísticas, o bien del índice 1, la clave primaria.
¡Y dónde leñes le digo que no quiero que haga lo que le de la gana! Pues la solución me ha dado ganas de estrangular a todos los indios programadores: añadiendo,
order by tablita.indice15
¿¡QUÉ!? ¡Order es para ordenar! Para mi siempre el order by se ha ejecutado después de tener en memoria todos los resultados de la select. Pues aquí no, aquí si lo pones estás obligando a la base de datos a usar ese índice. Me dan ganas de pegarme un tiro con cosas como estas, porque no es algo que puedas deducir, ¡se lo sacan de la manga! Y tampoco tengo acceso a ver la traza de las selects en Oracle, no se fían de mi T.T así que solo puedo saber si estoy haciendo una select mejor o peor, a ojo de buen cubero.
Lo que más rabia me da es enterarme de cosas como esta cuando llevo ya un año programando.
Y escribiendo esto, me viene una pregunta. Si quiero obligar a que la select utilice ese índice, pero yo quiero los resultados ordenados por otra cosa, ¿qué? ¿Ajo y agua? ¡Ja!
11 Respuestas en "Índices, drivers y mi desesperación"
Pues si lo necesitas ordenado, haces la chapuza padre y anidas otro select xD
De todas formas, es algo lógico, si lo quieres ordenado por otro campo… ¿para qué vas a usar el índice si tienes que revisar tupla por tupla?
Si metes otra select dentro, no haces nada, estás creando otra zona de memoria con otro puntero, aunque sea la misma tabla es algo permitido.
Sobre lo otro, puedo tener un índice 15 formado por, p.ej, localidad, nº de visita, persona, fecha
y querer traerme todas las visitas hechas a Madrid pero ordenadas por fecha de modo descendente, para tener en los primeros resultados las últimas visitas hechas.
Te lo vuelvo a repetir, ese índice sería prácticamente inútil, porque es específico de localidad-numero-persona-fecha. Con ese índice no te sirve de mucho si quieres hacer una búsqueda solamente por localidad-fecha. Para eso creas un nuevo índice localidad-fecha y sin problemas, si puedes permitirte el índice anterior, entonces este también. O uno solo de localidades, si son muchas.

Es lo mismo que si yo tengo un índice por nombre-dni, que, o me creo un índice nuevo por dni’s, o es inútil usar el primer índice para buscar un dni concreto.
En realidad, tu ejemplo sí que serviría de algo (suponiendo que la localidad no es siempre Madrid), pero la regla general es: si está organizado por x-y-z, puedo hacer búsquedas por x, por x-y o por x-y-z, pero en general no es muy útil hacerlas por x-z, y definitivamente no te sirve para nada si las vas a hacer por y o por z solamente.
A todo esto… ¿no te cansas de sql y, sobre todo, de Oracle?
Por eso yo no trabajo con máquinas, trabajo con niños, que son más fáciles de usar. Si no funcionan le metes un grito y listo
Ya Víctor, pero hay un límite de índices por tabla, y cuando tienes que hacer tropecientos informes diferentes con tablas de tropecientos registros, se piensa muy mucho qué índice crear. Además, cada vez que hacemos un índice, significa que tenemos que programar la parada del sistema para no dejar entrar a nadie, y reorganizar la tabla, que cuando es una gorda se puede tirar horas.
Por eso, aunque el índice que te propongo no sea la mejor opción, es buena porque ya estás filtrando por localidad usando un índice, o sea por x, y luego haciendo secuencial para encontrar las z que quieres.
De momento no me he cansado ^^. Creo que me cansaré cuando ya no haya nada que me sorprenda, entonces ya me buscaré otra cosa que aprender. Es lo bueno de la informática, que hay tantas y tantas cosas que aprender… y nunca paran de salir.
Fi2, tú sí que sabes.
Dije que iba a entrar por aquí más amenudo… pero veo que has empezado a hablar en chino :-s así que ya no entiendo nada! jajaja
Lo que haría yo en tú caso… apagar y volver a encender (ya, ya… demasiado típico)
Es que mira que tenéis trabajos complicados… con lo fácil que es tener uno en el que te puedes dedicar comentar en blogs ajenos (hombre, debería estar haciendo otras cosas, para qué nos vamos a engañar… pero si hay poco trabajo no es mi culpa!)
Fi2, seguro que son más fáciles los niños??? Que a esos no les puedes apagar!!! jajaja Uso ordenadores pero la informática es como la química para mi, no entiendo lo que no puedo ver! Y me encantan los niños… pero pueden llegar a ser agotadores :-s Vamos, que se llevan poco…
[qué chapa, perdón :-s]
A mi lo único que me mata de esa sentencia es el *, a no ser que vayas a usar todos y cada uno de los campos (que en este caso no lo puedo saber) es más rápido pedir sólo los campos que necesitas.
Según mi compañero, si vas a poner muchos campos puedes incluso ralentizarlo al ponerle uno a uno en vez de el asterisco. Yo mantengo mi idea de que no, de que ahorras memoria y siempre será más óptimo poner los campos que vayas a utilizar, pero estoy a sus órdenes. También es que es un coñazo tener que estar escribiendo uno a uno los campos… y que en el futuro te ahorras tocar código cuando quieras añadir una columna a un informe.
Como cada Base de Datos es un mundo, y probablemente esté diseñada en 5 minutos con millones de parches sólo puedo desearte suerte.Y paciencia, sobre todo paciencia.
Acabo de encontrar esto y me he acordado de este post.
Ese link es de oro, gracias Hugo.
Pon en funcionamiento esos deditos