Een "sort merge" join wordt uitgevoerd door de twee datasets die moeten worden samengevoegd volgens de join-sleutels te sorteren en ze vervolgens samen te voegen. Het samenvoegen is erg goedkoop, maar het soort kan onbetaalbaar zijn, vooral als het soort op schijf terechtkomt. De kosten van het soort kunnen worden verlaagd als een van de datasets in gesorteerde volgorde via een index kan worden geopend, hoewel toegang tot een groot deel van de blokken van een tabel via een indexscan ook erg duur kan zijn in vergelijking met een volledige tabelscan .
Een hash-join wordt uitgevoerd door een dataset in het geheugen te hashen op basis van join-kolommen en de andere te lezen en de hash-tabel te onderzoeken op overeenkomsten. De hash-join is zeer goedkoop wanneer de hash-tabel volledig in het geheugen kan worden bewaard, waarbij de totale kosten weinig meer bedragen dan de kosten van het lezen van de datasets. De kosten stijgen als de hash-tabel moet worden gemorst naar schijf in een sortering met één doorgang, en stijgen aanzienlijk voor een sortering met meerdere doorgangen.
(In pre-10g waren outer joins van een grote naar een kleine tafel prestatietechnisch problematisch, omdat de optimizer niet kon oplossen dat de kleinere tabel eerst moest worden geopend voor een hash-join, maar eerst de grotere tafel voor een outer join. Bijgevolg waren hash-joins in deze situatie niet beschikbaar).
De kosten van een hash-join kunnen worden verlaagd door beide tabellen op de join-sleutel(s) te partitioneren. Hierdoor kan de optimizer afleiden dat rijen van een partitie in de ene tabel alleen een overeenkomst zullen vinden in een bepaalde partitie van de andere tabel, en voor tabellen met n partities wordt de hash-join uitgevoerd als n onafhankelijke hash-joins. Dit heeft de volgende effecten:
- De grootte van elke hash-tabel wordt verkleind, waardoor de maximale hoeveelheid geheugen die nodig is, wordt verminderd en de bewerking mogelijk geen tijdelijke schijfruimte meer nodig heeft.
- Voor parallelle querybewerkingen wordt de hoeveelheid berichten tussen processen enorm verminderd, waardoor het CPU-gebruik wordt verminderd en de prestaties worden verbeterd, aangezien elke hash-join kan worden uitgevoerd door één paar PQ-processen.
- Voor niet-parallelle zoekbewerkingen wordt de geheugenvereiste verminderd met een factor n, en de eerste rijen worden eerder uit de zoekvraag geprojecteerd.
Houd er rekening mee dat hash-joins alleen kunnen worden gebruikt voor equi-joins, maar merge-joins zijn flexibeler.
Als u grote hoeveelheden gegevens in een equi-join samenvoegt, is een hash-join over het algemeen een betere keuze.
Dit onderwerp wordt zeer goed behandeld in de documentatie.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/optimops.htm#i51523
12.1 documenten:https://docs.oracle.com/database/121/TGSQL/tgsql_join.htm