Un moyen plus efficace de saisir la dernière valeur basée sur un indice composite?

Eh bien, la requête que vous avez écrite ne peut pas être appelée exactement "inefficace" mais "inutile" dans ce contexte car elle renverra une ligne aléatoire . Il vous manque probablement ORDER BY dans une sous-requête.

Quoi qu'il en soit: voyez comment cela se comporte:

select value
  from (select row_number() over (partition by car_type, color, car_brand
                                  order by submit_dt desc) rn,
               value
        from sample_table
        where car_type = rcar_type
          and color = rcolor
          and car_brand = rcar_brand
       )
where rn = 1;       

N'oubliez pas de créer un index sur les colonnes utilisées dans la clause WHERE .

Vous pouvez utiliser row_number pour résoudre ce problème.

Par exemple

SELECT x.value 
FROM (
  SELECT VALUE, 
         ROW_NUMBER() OVER (PARTITION BY CAR_TYPE, CAR_COLOR, CAR_BRAND ORDER BY SUBMIT_DATE DESC) AS RN
  FROM table
) x
WHERE x.RN = 1

Je suppose que vous vouliez dire "index" au lieu de "clé" dans votre question. Si tel est le cas, alors je créerais l'index:

select max(submit_dt)
from sample_table
where CAR_TYPE = rCar_Type
  and COLOR = rColor
  and CAR_BRAND = rCar_Brand

Ensuite, la requête suivante sera instantanée, car elle ne lira pas le tas:

create index ix1 on sample_table (car_type, color, car_brand, submit_dt);

Vous recherchez la dernière valeur par car_type , color , car_brand . Oracle propose KEEP LAST pour cela:

SELECT MAX(value) KEEP (DENSE_RANK LAST ORDER BY submit_dt)
  FROM table
 WHERE car_type = :rcar_type
   AND color = :rcolor
   AND car_brand = :rcar_brand;

Utilisez simplement FETCH FIRST :

SELECT *
FROM TABLE
WHERE CAR_TYPE = rCar_Type
  AND COLOR = rColor
  AND CAR_BRAND = rCar_Brand
ORDER BY submit_dt DESC
FETCH FIRST 1 ROW ONLY

Si votre version de la base de données est 12c.

Wow ... il y a déjà beaucoup de réponses, mais je pense que certaines d'entre elles ont manqué ce que je pense être le but de votre question.

Vous allez avoir des millions de lignes dans votre tableau et votre index composite sur (CAR_TYPE, COLOR, CAR_BRAND) ne sera pas très sélectif. Vous cherchez un moyen d'obtenir la ligne contenant le dernier SUBMIT_DT pour une entrée donnée dans votre index composite sans avoir à lire TOUTES les correspondances de cet index.

Réponse: ajoutez SUBMIT_DT DESC à votre index composite

Configurons un test:

--------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                 |     1 |    88 |    54   (2)| 00:00:01 |
|   1 |  SORT ORDER BY                 |                 |     1 |    88 |    54   (2)| 00:00:01 |
|*  2 |   VIEW                         |                 |     1 |    88 |    53   (0)| 00:00:01 |
|*  3 |    WINDOW NOSORT STOPKEY       |                 |   162 |  7290 |    53   (0)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| MATT_OBJECTS    |   162 |  7290 |    53   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | MATT_OBJECTS_N1 |   162 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=1)
   3 - filter(ROW_NUMBER() OVER ( ORDER BY SYS_OP_DESCEND("LAST_DDL_TIME"))<=1)
   5 - access("OBJECT_TYPE"='TABLE' AND "OWNER"='INV')

Maintenant, effectuons un suivi automatique de cette instruction :

drop index matt_objects_n1;

create index matt_objects_n1 on matt_objects ( object_type, owner, last_ddl_time desc );

exec dbms_stats.gather_table_stats(user,'MATT_OBJECTS');

---------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                 |     1 |    88 |    17   (6)| 00:00:01 |
|*  1 |  VIEW                                 |                 |     1 |    88 |    17   (6)| 00:00:01 |
|*  2 |   WINDOW SORT PUSHED RANK             |                 |   162 |  7290 |    17   (6)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| MATT_OBJECTS    |   162 |  7290 |    16   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | MATT_OBJECTS_N1 |   162 |       |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("from$_subquery$_002"."rowlimit_$$_rownumber"<=1)
   2 - filter(ROW_NUMBER() OVER ( ORDER BY INTERNAL_FUNCTION("LAST_DDL_TIME") DESC )<=1)
   4 - access("OBJECT_TYPE"='TABLE' AND "OWNER"='INV')

Résultat (de l'autotrace): 72 tampons de lecture cohérents sont obtenus

Maintenant, remplaçons votre index composite par un qui nous aidera plus: p>

select object_name
from   matt_objects
where  object_type = 'TABLE'
and    owner = 'INV'
order by last_ddl_time desc
fetch first 1 row only;

.. et répétons la même instruction automatiquement:

create table matt_objects as select * from dba_objects;

-- This is our analog of your composite index
create index matt_objects_n1 on matt_objects ( object_type, owner );

exec dbms_stats.gather_table_stats(user,'MATT_OBJECTS');

Résultat (de l'autotrace): 5 lecture cohérente obtient

Cet index a beaucoup aidé. Remarquez que le plan est différent? «WINDOW SORT PUSHED RANK» a été remplacé par «WINDOW NOSORT STOPKEY». L'index étant déjà trié comme vous le souhaitez (par ordre décroissant), Oracle sait qu'il peut lire les lignes d'index dans l'ordre et s'arrêter après la première - terminer la requête avec beaucoup moins d'effort.

C'est intéressant à noter que le coût de la 2ème requête est plus élevé que le coût de la 1ère requête, même si les performances de la 2ème requête sont plus de 10 fois meilleures. Cela montre simplement que le "coût" est une estimation et doit parfois être pris avec un grain de sel.