Optimización Select (INDICE se coge con operador IN )

[Jonathan Barrio Rodriguez]

Buenas...

Exposicion de la circunstancia:
Me informan que una select hace una lectura secuencial, está en un job que lleva 2 días ahí atascado (por supuesto, el número de registros es elevadísimo) y que hay un indice que no se está aprobechando.


Consultas:
¿ Utiliza la select el indice si el operador de comparación es un "IN" ?
¿ Existe alguna herramienta en R/3 qué me indique si ese indice se usará o no?
¿ Tendrá alguna incidencia el hecho que la igualdad del FOR ALL ENTRIES IN no esté en la primera condición del WHERE ?

Código (Las dos alternativas compilan):
*DECLARACION DE DATOS:
data: r_fecha type range of sy-datum,
wa_fecha like line of r_fecha,
w_interr_ele_aux type standard table of zcali_interr_ele,
w_interr_ele type standard table of zcali_interr_ele.

FREE: r_fecha, wa_fecha.

CONCATENATE:
SY-DATUM(4) '0101' INTO wa_fecha-low,
SY-DATUM(4) '1231' INTO wa_fecha-high.
Move: 'I' TO wa_fecha-sign,
'BT' TO wa_fecha-option.
APPEND wa_fecha to r_fecha.

1ª sin indice.
SELECT
MANDT
ID_INCIDENCIA
VSTELLE
ANLAGE
FECHA_MODIF
HORA_MODIF
AB
ATIME
BUKRS
GPART
VERTRAG
DURACION
CAUSA
CLASIFICACION
ZONA
STATUS
ID_USUARIO
FROM
zcali_interr_ele APPENDING TABLE w_interr_ele
FOR ALL ENTRIES IN w_interr_ele_aux
WHERE vstelle = w_interr_ele_aux-vstelle
AND ab IN r_fecha
AND causa = '0200'
*and clasificacion in ('0204', '0205', '0201')
AND status = 'APCA'.

2ª respetando el indice.
SELECT
MANDT
ID_INCIDENCIA
VSTELLE
ANLAGE
FECHA_MODIF
HORA_MODIF
AB
ATIME
BUKRS
GPART
VERTRAG
DURACION
CAUSA
CLASIFICACION
ZONA
STATUS
ID_USUARIO
FROM
zcali_interr_ele APPENDING TABLE w_interr_ele
FOR ALL ENTRIES IN w_interr_ele_aux
WHERE ab IN r_fecha
AND causa = '0200'
*and clasificacion in ('0204', '0205', '0201')
AND status = 'APCA'
AND vstelle = w_interr_ele_aux-vstelle.



Saludos a todos y
como siempre, muchas gracias a todos.

[DavidXD_XD]

Hola doc, pues no o al menos parece q no, pues una vez me toco realizar un Performance de un SELECT que consultaba con IN, y pues no cogia el indice, me toco realizar un LOOP para apuntar al indice directo, claro que era un indice por sociedades y no hay muchas (20), pero cada una de ellas tenia una elevada cantidad de registros y la herramienta para poder ver si se hace uso correcto de la BD es:

Dialogo: ST05
Dialogo y JOB: DBACOCKPIT

Esta ultima transaccion es muy potente pero es un tema ... los de BASIS y administradores de BD son los que lo manejan muy seguido, espero habert ayudado

[Jonathan Barrio Rodriguez]

Pues sí, David, gracias, como siempre, de mucha ayuda.
Al final nos hemos quedado por seguir el indice, a pesar que yo opino como tú en que no lo va a seguir.

Pienso que sería mejor seguir el campo STATUS, ya que es de caracter boleano y ademas el valor que estoy introduciendo es de menor coincidencía. Esto restringiría de forma importante el acceso.
ST05 ya la conocía, DBACOCKPIT no, y parece una herramienta interesante, pero no he podido utilizarla (pedía ingresar un sistema para RFC), a ver si con el tiempo les voy sacando partido a estas herramientas.

Gracias compi.

SELECT
MANDT
ID_INCIDENCIA
VSTELLE
ANLAGE
FECHA_MODIF
HORA_MODIF
AB
ATIME
BUKRS
GPART
VERTRAG
DURACION
CAUSA
CLASIFICACION
ZONA
STATUS
ID_USUARIO
FROM
zcali_interr_ele APPENDING TABLE w_interr_ele
FOR ALL ENTRIES IN w_interr_ele_aux
WHERE ab IN r_fecha
AND causa = '0200'
*and clasificacion in ('0204', '0205', '0201')
AND status = 'APCA'
AND vstelle = w_interr_ele_aux-vstelle.

[VLozano]

Que yo recuerde de mis tiempos mozos, en cuanto el DMBS encuentra un IN, deja de mirar índices. Así pues, si tienes un IN, aunque apunte al campo clave de una tabla, todo al carajo.
Lo ideal sería buscar (o crear) un índice alternativo para los otros campos de las condiciones. Si no lo hay (o no te dejan crearlo), y la cosa realmente está chunga, buscar un algorismo para tratar el rango del IN y realizar búsquedas consecutivas usando APPENDING TABLE en vez de INTO TABLE.

Un apunte: si no compruebas que la tabla que se utiliza en el FOR ALL ENTRIES tiene al menos un registro, la SQL se va al carajo y te trae TODA LA TABLA, independientemente de lo que pueda haber en el WHERE.