En "sort fletning" sammenføjning udføres ved at sortere de to datasæt, der skal sammenføjes, i henhold til sammenføjningsnøglerne og derefter flette dem sammen. Sammenlægningen er meget billig, men sorteringen kan være uoverkommelig dyr, især hvis sorteringen spildes til disken. Prisen for sorteringen kan sænkes, hvis et af datasættene kan tilgås i sorteret rækkefølge via et indeks, selvom det også kan være meget dyrt at få adgang til en høj andel af blokke af en tabel via en indeksscanning i forhold til en fuld tabelscanning .
En hash-join udføres ved at hashe et datasæt ind i hukommelsen baseret på join-kolonner og læse den anden og undersøge hash-tabellen for matches. Hash join er meget lav pris, når hash-tabellen kan opbevares helt i hukommelsen, hvor de samlede omkostninger beløber sig til meget lidt mere end omkostningerne ved at læse datasættene. Omkostningerne stiger, hvis hash-tabellen skal spildes på disken i en engangssortering, og stiger betydeligt for en flergangssortering.
(I præ-10g var ydre sammenføjninger fra et stort til et lille bord problematiske ydelsesmæssigt, da optimeringsværktøjet ikke kunne løse behovet for at få adgang til den mindre tabel først for en hash-sammenføjning, men den større tabel først for en ydre sammenføjning. Derfor var hash-join ikke tilgængelige i denne situation).
Omkostningerne ved en hash-join kan reduceres ved at partitionere begge tabeller på join-nøglen(erne). Dette gør det muligt for optimeringsværktøjet at udlede, at rækker fra en partition i én tabel kun vil finde et match i en bestemt partition i den anden tabel, og for tabeller med n partitioner udføres hash-sammenføjningen som n uafhængige hash-sammenføjninger. Dette har følgende virkninger:
- Størrelsen af hver hash-tabel reduceres, hvilket reducerer den maksimale mængde hukommelse, der kræves, og fjerner muligvis behovet for, at handlingen kræver midlertidig diskplads.
- For parallelle forespørgselsoperationer reduceres mængden af meddelelser mellem processer markant, hvilket reducerer CPU-brug og forbedrer ydeevnen, da hver hash-join kan udføres af et par PQ-processer.
- For ikke-parallelle forespørgselsoperationer reduceres hukommelseskravet med en faktor n, og de første rækker projiceres fra forespørgslen tidligere.
Du skal bemærke, at hash-joins kun kan bruges til equi-joins, men merge-joins er mere fleksible.
Generelt, hvis du forbinder store mængder data i en equi-join, vil en hash-join være et bedre bud.
Dette emne er meget godt dækket i dokumentationen.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/optimops.htm#i51523
12.1 docs:https://docs.oracle.com/database/121/TGSQL/tgsql_join.htm