Indices Oracle

[matanga]

Esto depende de varios factores, además de las condiciones del WHERE, también está la cardinalidad (cantidad de valores diferentes en una columna), las columnas en el ORDER BY y las columnas en el SELECT.

Según lo entiendo, la columna expediente supone una cardinalidad alta y la columna estado tiene una cardinalidad=2 (valores 0 y 1) que se considera muy baja, en estos casos, el optimizador resolverá el WHERE primero por expediente y después por estado, lo que sugiere:

1. Si el subconjunto de filas resultantes de filtrar por expediente es bajo, se recomienda crear un solo índice sobre la columna expediente, y dejar que el optimizador haga un fullscan sobre el subconjunto para filtrar el estado, ya que esto puede ser más óptimo que mantener un segundo índice en una tabla con 12 millones de registros.

2. Si el subconjunto de filas resultantes de filtrar por expediente es alto y detectas que el fullscan sobre el subconjunto para filtrar el estado es lento, se recomienda crear un índice sobre la columna expediente y un segundo índice pero de tipo bitmap (diseñados para valores True|False, 0|1, etc) sobre la columna estado.

3. Y se recomienda crear un solo índice compuesto por los dos campos cuando, además de formar la condición del WHERE, los campos son los únicos en el SELECT (ej: select expediente, estado from expedientes...) porque evita el acceso a la tabla para leer los datos, y/o cuando son los únicos en el ORDER BY (ej: select * from expedientes where .... order by expediente, estado) ya que la ordenación de la consulta no se ejecuta si coincide con la ordenación del índice.

De todos modos, estas recomendaciones son en general, siempre es mejor evaluar el rendimiento ejecutando las consultas comparando los tiempos y planes de ejecución.

Saludos