Index non utilisé sur une base

Si je vous montre la requete, vous prendriez peur :)
C'est une requete générée par Hibernate.

Bahh
je vais laisser les developpeurs réfléchir plutot, car pour moi, c'est clairement un probleme de volumétrie.

Petite question d'ailleur.

Dans le plan d'execution, la colonne Row, elle correspond au nombre totale des data dans la table, ou dans l'indexe ? ou de l'estimate ?

Hibernate il faut s'arrêter aux requêtes simples.

Dès que c'est compliqué, vous mettez la requête dans une vue et vous appelez la vue.

Bonjour,

Citation:

---

Envoyé par pacmann

Si tu veux tenter les hints, c'est effectivement dans le select :
/*+ use_nl(tablea, tableb) index(tableb tonindex*/

---

Pour hinter, un exemple ici avec la manière précise de hinter les jointures.

Mais la meilleure manière d'appliquer le plan d'exécution d'un environnement à un autre est de prendre le plan d'exécution avec le format '+OUTLINE' et récupérer les hints. Puis comme le précise Mohamed on compare les estimations.

Citation:

---

Envoyé par Waldar

Hibernate il faut s'arrêter aux requêtes simples.
Dès que c'est compliqué, vous mettez la requête dans une vue et vous appelez la vue.

---

Attention, si on dit trop ça. Hibernate peut aussi envoyer un million de requêtes simples à la place - c'est pas mieux ;)

Cordialement,
Franck.

Citation:

---

Envoyé par Le-DOC

Dans le plan d'execution, la colonne Row, elle correspond au nombre totale des data dans la table, ou dans l'indexe ? ou de l'estimate ?

---

La colonne ROW correspond au nombre d'enregistrements retournés dans l'opération.

Citation:

---

Envoyé par Mohamed.Houri

J'avoue également que je n'ai pas bien saisi le rôle de l'inversion des colonnes de l'index dans ce cas où les deux colonnes sont utilisées dans la where clause et que les prédicats sur ces deux colonnes sont des égalités.

---

Prenons un cas de 2 tables A (idA), B (idB), et une table de jointure C (idA, idB).

Chaque table fait 10 millions de ligne, et il y a une jointure 1:1 entre A et B. Je fais une requête simple avec une restriction sur B qui filtre sur une seule ligne.

Alors l'index (idA,idB) est peu intéressant :
> Ou bien j'ouvre la table A, je fais une jointure avec l'index (10 millions de ligne), puis je joins B, et enfin je filtre pour me retrouver avec une seule ligne.
> Ou bien je pars de B, je n'ai qu'une seule ligne, mais ensuite je doit parcourir tout mon index pour trouver la ligne correspondante ... j'ai donc du lire tout l'index !

Au contraire, l'index (idB,idA) me permet de faire :
> Je pars de B, je trouve la ligne qui correspondà mes filtres
> J'utilise l'index pour en déduire idA (accès rapide par l'index)
> Je récupère la ligne dans A.

=> Bien sûr, ici j'ai grossi le trait. Dans la réalité, on aurait des stats plus équilibrées, des filtres des deux côtés, mais qui ramèneraient 500k lignes d'un côté, et 50 de l'autre (et la combinaison des deux, 10 lignes).

J'ai assez souvent, sur ces tables de jointures volumineuses, des index "croisés", (idA,idB) et (idB, idA).

Bonjour,
(peut-être un peu hors sujet - ma réponse ne concerne que le dernier post)

Citation:

---

Envoyé par Rei Ichido

J'ai assez souvent, sur ces tables de jointures volumineuses, des index "croisés", (idA,idB) et (idB, idA).

---

Ca me paraît tout à fait normal d'avoir ces deux index pour une table d'association vu qu'il y a les 2 navigations possibles, même si ça revient à stocker 3 fois la même ligne, mais dans des ordres différents.
On peut économiser le stockage de la table en créant une Index Organized table sur (idA,idB) et un index secondaire sur (idB, idA). C'est souvent un des cas idéal pour les IOT (car la clé primaire se trouve partout).
Cordialement,
Franck

@ Rei Ichido

Le mieux c'est d'avoir un modèle sur lequel on peut discuter. Pour l'instant cela reste trop théorique et quelques subtilités peuvent apparaître lorsque vous vous exprimerez par le biais d’un exemple pratique.