Un join "sort merge" viene eseguito ordinando i due set di dati da unire in base alle chiavi di join e quindi unendoli insieme. L'unione è molto economica, ma l'ordinamento può essere proibitivo soprattutto se l'ordinamento si riversa su disco. Il costo dell'ordinamento può essere ridotto se è possibile accedere a uno dei set di dati in ordine ordinato tramite un indice, sebbene l'accesso a un'elevata percentuale di blocchi di una tabella tramite una scansione dell'indice possa anche essere molto costoso rispetto a una scansione completa della tabella .
Un hash join viene eseguito eseguendo l'hashing di un set di dati in memoria in base alle colonne di join e leggendo l'altro e sondando la tabella hash per le corrispondenze. L'hash join ha un costo molto basso quando la tabella hash può essere conservata interamente in memoria, con il costo totale che ammonta a poco più del costo della lettura dei set di dati. Il costo aumenta se la tabella hash deve essere trasferita su disco in un ordinamento a passaggio singolo e aumenta considerevolmente per un ordinamento a più passaggi.
(In pre-10g, i join esterni da una tabella grande a una piccola erano problematici dal punto di vista delle prestazioni, poiché l'ottimizzatore non poteva risolvere la necessità di accedere prima alla tabella più piccola per un hash join, ma alla tabella più grande prima per un join esterno. Di conseguenza gli hash join non erano disponibili in questa situazione).
Il costo di un hash join può essere ridotto partizionando entrambe le tabelle sulle chiavi di join. Ciò consente all'ottimizzatore di dedurre che le righe di una partizione in una tabella troveranno una corrispondenza solo in una particolare partizione dell'altra tabella e per le tabelle con n partizioni l'hash join viene eseguito come n hash join indipendenti. Ciò ha i seguenti effetti:
- Le dimensioni di ciascuna tabella hash vengono ridotte, riducendo così la quantità massima di memoria richiesta e potenzialmente eliminando la necessità che l'operazione richieda spazio su disco temporaneo.
- Per le operazioni di query parallele, la quantità di messaggistica tra processi è notevolmente ridotta, riducendo l'utilizzo della CPU e migliorando le prestazioni, poiché ogni hash join può essere eseguito da una coppia di processi PQ.
- Per le operazioni di query non parallele, il requisito di memoria viene ridotto di un fattore n e le prime righe vengono proiettate in precedenza dalla query.
Tieni presente che gli hash join possono essere utilizzati solo per gli equi-join, ma i merge join sono più flessibili.
In generale, se stai unendo grandi quantità di dati in un equi-join, un hash join sarà una scommessa migliore.
Questo argomento è trattato molto bene nella documentazione.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/optimops.htm#i51523
12.1 documenti:https://docs.oracle.com/database/121/TGSQL/tgsql_join.htm
