Oracle 10g - optimizar DONDE NO ES NULO

Question

Tenemos Oracle 10g y necesitamos consultar 1 tabla (sin uniones) y filtrar filas donde 1 de las columnas es nula. Cuando hacemos esto - DONDE OurColumn IS NOT NULL - obtenemos un escaneo de tabla completo en una mesa muy grande - MAL MALO MALO. La columna tiene un índice pero se ignora en esta instancia. ¿Hay alguna solución para esto?

Gracias

Answer 1

El optimizador cree que la exploración de tabla completa será mejor.

Si solo hay unas pocas filas NULL, el optimizador es correcto.

Si está absolutamente seguro de que el índice de acceso será más rápido (es decir, tiene más de 75% filas con col1 IS NULL), luego insinuar su consulta:

SELECT /*+ INDEX (t index_name_on_col1) */ 
     * 
FROM mytable t 
WHERE col1 IS NOT NULL 

Por qué 75%?

Dado que el uso para recuperar los valores que no están cubiertos por el índice implica una oculta unirse en ROWID, que cuesta unos 4 veces más que el recorrido de tabla.

Si el rango de índice incluye más de 25% de filas, el escaneo de tabla suele ser más rápido.

Como se menciona por Tony Andrews, el factor de agrupamiento es el método más preciso para medir este valor, pero 25% sigue siendo una buena regla empírica.

Answer 2

Si usted está haciendo un select *, entonces tendría sentido hacer un recorrido de tabla en lugar de utilizar el índice. Si sabe en qué columnas está interesado, puede crear un índice cubierto con esas columnas más el que está aplicando la condición IS NOT NULL.

Answer 3

Cree un índice en esa columna.

Para asegurarse de que se utiliza el índice, debe estar en el índice y otras columnas en el where.

ocdecio respondió:

Si usted está haciendo un select *, entonces tendría sentido hacer una mesa de estudio en lugar de utilizar el índice.

Eso no es estrictamente cierto; se usará un índice si hay un índice que se ajuste a su cláusula where, y el optimizador de consultas decida que usar ese índice sería más rápido que hacer una exploración de tabla. Si no hay índice, o no hay índice adecuado, solo entonces se debe realizar un escaneo de tabla.

Answer 4

El optimizador tomará su decisión en función del costo relativo de la exploración de tabla completa y el uso del índice. Esto se reduce principalmente a cuántos bloques tendrán que leerse para satisfacer la consulta. La regla de 25%/75% mencionada en otra respuesta es simplista: en algunos casos, una exploración completa de la tabla tendrá sentido incluso para obtener el 1% de las filas, es decir, si esas filas se distribuyen en muchos bloques.

Por ejemplo, considere la siguiente tabla:

SQL> create table t1 as select object_id, object_name from all_objects; 

Table created. 
SQL> alter table t1 modify object_id null; 

Table altered. 

SQL> update t1 set object_id = null 
    2 where mod(object_id,100) != 0 
    3/

84558 rows updated. 

SQL> analyze table t1 compute statistics; 

Table analyzed. 

SQL> select count(*) from t1 where object_id is not null; 

    COUNT(*) 
---------- 
     861  

Como se puede ver, sólo aproximadamente el 1% de las filas de T1 tiene un object_id no nulo.Pero debido a la forma en que construí la tabla, estas 861 filas se distribuirán más o menos uniformemente alrededor de la mesa. Por lo tanto, la consulta:

select * from t1 where object_id is not null; 

es probable que visitar casi todos los bloques de la T1 para obtener los datos, incluso si el optimizador utiliza el índice. ¡Tiene sentido entonces prescindir del índice y realizar un escaneo completo de la tabla!

Una estadística clave para ayudar a identificar esta situación es el factor de índice de agrupación:

SQL> select clustering_factor from user_indexes where index_name='T1_IDX'; 

CLUSTERING_FACTOR 
----------------- 
       460 

Este valor 460 es bastante alto (en comparación con las 861 filas en el índice), y sugiere que un escaneo completo de tabla se ser usado. Ver this DBAZine article on clustering factors.

Answer 5

Puede depender del tipo de índice que tenga sobre la mesa.

La mayoría de los índices B-tree do no almacenar entradas nulas. Los índices de mapa de bits hacen almacenar entradas nulas.

lo tanto, si usted tiene:

seleccionar * de mitabla donde micolumna es nulo

y tiene un índice de árbol B de serie en mycolumn, la consulta no puede use el índice ya que el "nulo" no está en el índice.

(Si el índice está en contra de varias columnas, y una de las columnas indizadas no es nulo, entonces habrá una entrada en el índice.)

Answer 6

También vale la pena comprobar si las estadísticas de Oracle en la tabla son hasta fecha. Es posible que no sepa que una exploración de tabla completa será más lenta.

Answer 7

Ver http://www.oracloid.com/2006/05/using-index-for-is-null/

Si el índice está en un solo campo, no va a ser utilizado. Trate de añadir un campo ficticio o una constante en el índice: base de datos de

create index tind on t(field_to_index, 1); 

Answer 8

Oracle do valores nulos no indexa en absoluto en índices (b) de árboles regulares, por lo que no se puede usar ni se puede' t forzar la base de datos Oracle para usarlo.

BR

Answer 9

El uso de sugerencias debe hacerse solo como una solución alternativa en lugar de una solución.

Como se menciona en otras respuestas, el valor nulo no está disponible en los índices B-TREE.

Dado que sabe que tiene en su mayoría valores nulos en esta columna, ¿podría reemplazar el valor nulo por un rango, por ejemplo?

Eso realmente depende de su columna y la naturaleza de sus datos, pero por lo general, si su columna es un tipo de fecha, por ejemplo:

where mydatecolumn is not null se puede traducir en una regla que dice: Quiero todas las filas que tienen una fecha.

A continuación, puede sin duda hacer esto: donde mydatecolumn < = sysdate (en Oracle)

Esto devolverá todas las filas con una fecha y ommit valores nulos, mientras que aprovechando el índice en esa columna sin utilizar ningún consejos.