distinct... y index de tabla

[tricampeon27]

hola buenas

quisiera hacer una consulta , tengo una query bastante pesada en tiempo de respuesta , esta query tiene un select distinct el cual quisiera saber si es verdad que esta sentencia mata el indice , osea no lo ocupada el cual estoy utilizando en mi where

bueno espero que me puedan ayudar.


Slds

[xf_corp]

Hola,

Cual es el query? Y especifica cual o cuales son las columnas indexadas, así como el tipo de index normal o compuesto.

Saludos!

[tricampeon27]

Iniciado por xf_corp

Hola,

Cual es el query? Y especifica cual o cuales son las columnas indexadas, así como el tipo de index normal o compuesto.

Saludos!

hola como estas.

la verdad que es un query bastante grande y no vale la pena ponerlo aca para la duda que tengo por ejemplo

digamos si tengo esto:

select distinct campo1,
campo2,
campo3
from tabla1
where campo6 = 10
and campo7 = 20
group by campo6, campo7


donde el indice de la tabla es por el campo 6,7

el plan table me muestra que efectivamente se va por dichos campo

pero he leido que distinct mata los indice sabes si eso es cierto????

Slds

[xf_corp]

Hola, Bien Gracias y Tú?

Te preguntaba cual era el query porque independientemente de si usaras DISTINCT en el SELECT, si efectuas las búsqueda y las columnas que aparecen en el SELECT estan indexadas, podrías devolver los valores directamente del index, sin necesidad del ACCESS FULL de la tabla aunque no estuviesen indexados los campos de búsqueda. Acorde a tu ejemplo al parecer no es el caso.

Para validar si no te hace ACCESS FULL TABLE revisa el xplain plan, con algo como lo siguiente:

Código:

explain plan for
SELECT columns FROM table(s) WHERE filter... --//ahi sustituirías por tu query.

select plan_table_output
    from table(dbms_xplan.display('plan_table',null,'basic'));

Si como mencionas si va por esos campos, entonces no problem

Ejemplificando con el schema de HR de Oracle:

Código:

--//Realiza el acceso a través de la columna indexada a pesar de distinct aun cuando las columnas seleccionadas no están todas indexadas...
select distinct employee_id, first_name 
from hr.employees where DEPARTMENT_ID=110;

--//Aquí aunque no se especifican columnas de búsqueda con WHERE, no se realiza ACCESS FULL, debido a que la columna seleccionada se encuentra indexada...
select max(DEPARTMENT_ID)
from  hr.employees;

So, revisa el xplain plan, y asi despejaras la duda...

Como nota adicional dependiendo del número de filas de las tablas accesadas, el ACCESS FULL no siempre es negativo, si por ejemplo se trata de una tabla con pocos registros.

Saludos!

[tricampeon27]

xplan es diferente a plan_table ????

are este ejerciocio haber como me va

Slds

[xf_corp]

Plan_Table:
http://docs.oracle.com/cd/B28359_01/...views_5127.htm

Explain Plan:
http://docs.oracle.com/cd/B28359_01/...plan.htm#i3305

Saludos!

[matanga]

Iniciado por xf_corp

Te preguntaba cual era el query porque independientemente de si usaras DISTINCT en el SELECT, si efectuas las búsqueda y las columnas que aparecen en el SELECT estan indexadas, podrías devolver los valores directamente del index, sin necesidad del ACCESS FULL de la tabla aunque no estuviesen indexados los campos de búsqueda.

Esto no es realmente así, los valores del select nunca se leen del índice cuando el where se resuelve desde la tabla, por ejemplo:

Código:

create table t1 (id numeric(8), nombre varchar2(10));
create index idx_t1_id on t1(id);

select id from t1 where id = 1;
--utiliza el índice para el where y el select

select nombre from t1 where id = 1;
--utiliza el índice para el where y la tabla para el select

select id from t1 where nombre = 'pepe';
--utiliza la tabla para el where y el select, nunca el índice

select distinct nombre from t1 where id = 1;
--utiliza el índice para el where y la tabla para el select

select distinct id from t1 where id = 1;
--utiliza el índice para el where y el select

Saludos

[xf_corp]

Tienes razón, tendrían que estar indexados tanto las columnas del WHERE como del SELECT, para omitir el acceso a la tabla, o no existir WHERE :P, como complemento al tema:

http://www.orafaq.com/tuningguide/hi...l%20index.html


http://docs.oracle.com/cd/B28359_01/...s.htm#autoId31
11.5.3.6 Full Scans
A full index scan eliminates a sort operation, because the data is ordered by the index key. It reads the blocks singly. A full scan is used in any of the following situations:

An ORDER BY clause that meets the following requirements is present in the query:

All of the columns in the ORDER BY clause must be in the index.

The order of the columns in the ORDER BY clause must match the order of the leading index columns.

The ORDER BY clause can contain all of the columns in the index or a subset of the columns in the index.

The query requires a sort merge join. A full index scan can be done instead of doing a full table scan followed by a sort if the query meets the following requirements:

All of the columns referenced in the query must be in the index.

The order of the columns referenced in the query must match the order of the leading index columns.

The query can contain all of the columns in the index or a subset of the columns in the index.

A GROUP BY clause is present in the query, and the columns in the GROUP BY clause are present in the index. The columns do not need to be in the same order in the index and the GROUP BY clause. The GROUP BY clause can contain all of the columns in the index or a subset of the columns in the index.


11.5.3.7 Fast Full Index Scans
Fast full index scans are an alternative to a full table scan when the index contains all the columns that are needed for the query, and at least one column in the index key has the NOT NULL constraint. A fast full scan accesses the data in the index itself, without accessing the table. It cannot be used to eliminate a sort operation, because the data is not ordered by the index key. It reads the entire index using multiblock reads, unlike a full index scan, and can be parallelized.

You can specify fast full index scans with the initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint. Fast full index scans cannot be performed against bitmap indexes.

A fast full scan is faster than a normal full index scan in that it can use multiblock I/O and can be parallelized just like a table scan.

Saludos!