¿Cómo puedo acelerar row_number en Oracle?

Question

Tengo una consulta SQL que se ve algo como esto:

SELECT * FROM(
    SELECT 
     ..., 
     row_number() OVER(ORDER BY ID) rn 
    FROM 
     ... 
) WHERE rn between :start and :end 

Esencialmente, es el ORDER BY parte que es frenar las cosas. Si tuviera que eliminarlo, el costo EXPLAIN disminuye en un orden de magnitud (más de 1000x). Intenté esto:

SELECT 
    ... 
FROM 
    ... 
WHERE 
    rownum between :start and :end 

Pero esto no da los resultados correctos. ¿Hay alguna manera fácil de acelerar esto? ¿O tendré que pasar más tiempo con la herramienta EXPLAIN?

Answer 1

ROW_NUMBER es bastante ineficiente en Oracle.

Ver el artículo en mi blog para los detalles de rendimiento:

• Oracle: ROW_NUMBER vs ROWNUM

Para su consulta específica, me gustaría recomendar que reemplazarlo con ROWNUM y asegurarse de que se utiliza el índice :

SELECT * 
FROM (
     SELECT /*+ INDEX_ASC(t index_on_column) NOPARALLEL_INDEX(t index_on_column) */ 
       t.*, ROWNUM AS rn 
     FROM table t 
     ORDER BY 
       column 
     ) 
WHERE rn >= :start 
     AND rownum <= :end - :start + 1 

Esta consulta utilizará COUNT STOPKEY

También, o bien asegúrese de que column no sea nulo, o agregue la condición WHERE column IS NOT NULL.

De lo contrario, el índice no se puede utilizar para recuperar todos los valores.

Tenga en cuenta que no puede usar ROWNUM BETWEEN :start and :end sin una subconsulta.

ROWNUM siempre se asigna al último y se marca el último, así es ROWNUM siempre vienen en orden sin espacios.

Si utiliza ROWNUM BETWEEN 10 and 20, la primera fila que satisifies todas las demás condiciones se convertirá en un candidato para el retorno, asignado temporalmente con ROWNUM = 1 y no pasan la prueba de ROWNUM BETWEEN 10 AND 20.

Luego, la siguiente fila será candidata, se le asignará ROWNUM = 1 y se producirá un error, etc., por lo que, finalmente, no se devolverán las filas.

Esto debería solucionarse poniendo ROWNUM en la subconsulta.

Answer 2

¿Está su columna ORDER BY indexada? Si no, ese es un buen lugar para comenzar.

Answer 3

Pase más tiempo con la herramienta EXPLAIN PLAN. Si ve una TABLA DE ESCANEAR, debe cambiar su consulta.

Su consulta tiene poco sentido para mí. Consultar sobre un ROWID parece pedir problemas. No hay información relacional en esa consulta. ¿Es la consulta real con la que tiene problemas o un ejemplo que inventó para ilustrar su problema?

Answer 4

Parece una consulta de paginación para mí.

De este artículo ASKTOM (alrededor del 90% abajo de la página):

You need to order by something unique for these pagination queries, so that ROW_NUMBER is assigned deterministically to the rows each and every time.

también sus consultas son no está cerca de la misma así que no estoy seguro de lo que el beneficio de la comparación de los costos de una para el otro es.

Answer 5

Parte del problema es qué tan grande es el lapso de 'inicio' a 'final' y dónde 'viven'. Digamos que tiene un millón de filas en la tabla, y quiere las filas 567,890 a 567,900, entonces tendrá que vivir con el hecho de que tendrá que pasar por toda la tabla, ordenar todo eso por ID , y averigüe qué filas caen en ese rango.

En resumen, eso es mucho trabajo, por lo que el optimizador le da un alto costo.

Tampoco es algo que un índice pueda ayudar mucho. Un índice daría la orden, pero en el mejor de los casos, eso le da un lugar para comenzar y luego continúa leyendo hasta llegar a la entrada 567.900.

Si le muestra a su usuario final 10 elementos a la vez, puede valer la pena realmente agarrar los 100 mejores de la base de datos, y luego tener la aplicación dividir esos 100 en diez pedazos.