Join SQL espliciti vs impliciti

C'è qualche differenza di efficienza in un join interno esplicito vs implicito? Per esempio:

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

vs.

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

Per quanto riguarda le prestazioni, sono esattamente le stesse (almeno in SQL Server).

PS: tenere presente che la IMPLICIT OUTER JOINsintassi è obsoleta da SQL Server 2005. (La IMPLICIT INNER JOINsintassi utilizzata nella domanda è ancora supportata)

Deprecazione della sintassi JOIN "Old Style": solo una cosa parziale

Personalmente preferisco la sintassi del join in quanto rende più chiaro che le tabelle sono unite e come sono unite. Prova a confrontare query SQL più grandi in cui selezioni tra 8 diverse tabelle e hai un sacco di filtri nel dove. Utilizzando la sintassi di join, si separano le parti in cui le tabelle sono unite, alla parte in cui si stanno filtrando le righe.

Su MySQL 5.1.51, entrambe le query hanno piani di esecuzione identici:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1ha 166208 file; table2ha circa 1000 file.

Questo è un caso molto semplice; non dimostra in alcun modo che Query Optimizer non si confonderebbe e non genererebbe piani diversi in un caso più complicato.

La seconda sintassi ha la possibilità indesiderata di un cross join: è possibile aggiungere tabelle alla parte FROM senza la corrispondente clausola WHERE. Questo è considerato dannoso.

La prima risposta che hai dato utilizza la cosiddetta sintassi del join ANSI, l'altra è valida e funzionerà in qualsiasi database relazionale.

Sono d'accordo con grom che dovresti usare la sintassi del join ANSI. Come hanno detto, il motivo principale è la chiarezza. Invece di avere una clausola where con molti predicati, alcuni dei quali uniscono tabelle e altri che limitano le righe restituite con la sintassi del join ANSI, stai chiarendo in modo accecante quali condizioni vengono utilizzate per unire le tue tabelle e quali vengono utilizzate per limitare il risultati.

Per quanto riguarda le prestazioni, sono esattamente le stesse (almeno in SQL Server) ma attenzione che stanno deprecando questa sintassi del join e non è supportata da sql server2005 pronto all'uso.

Penso che tu stia pensando agli operatori deprecati * = e = * rispetto a "join esterno".

Ho appena testato i due formati indicati e funzionano correttamente su un database SQL Server 2008. Nel mio caso hanno prodotto piani di esecuzione identici, ma non potevo dire con certezza che ciò sarebbe sempre vero.

@lomaxx: Giusto per chiarire, sono abbastanza certo che entrambe le sintassi sopra sono supportate da SQL Serv 2005. Tuttavia, la sintassi di seguito NON è supportata

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

In particolare, il join esterno (* =) non è supportato.

In alcuni database (in particolare Oracle), l'ordine dei join può fare un'enorme differenza per le prestazioni delle query (se sono presenti più di due tabelle). Su una domanda, in alcuni casi avevamo letteralmente due ordini di differenza di grandezza. L'uso della sintassi del join interno ti dà il controllo su questo - se usi la sintassi dei suggerimenti giusti.

Non hai specificato quale database stai usando, ma la probabilità suggerisce SQL Server o MySQL dove non fa alcuna differenza.

Come ha affermato Leigh Caldwell, Query Optimizer è in grado di produrre diversi piani di query in base a ciò che sembra funzionalmente simile alla stessa istruzione SQL. Per ulteriori approfondimenti, dai un'occhiata ai seguenti due post sul blog: -

Un post del team Oracle Optimizer

Un altro post dal blog "Dati strutturati"

Spero che lo trovi interessante.

Per quanto riguarda le prestazioni, non dovrebbe fare alcuna differenza. La sintassi del join esplicito mi sembra più pulita in quanto definisce chiaramente le relazioni tra le tabelle nella clausola from e non ingombra la clausola where.

Fondamentalmente, la differenza tra i due è che uno è scritto alla vecchia maniera, mentre l'altro è scritto alla maniera moderna. Personalmente, preferisco la sceneggiatura moderna usando le definizioni interne, sinistra, esterna, destra perché sono più esplicative e rendono il codice più leggibile.

Quando si ha a che fare con i join interni non vi è alcuna reale differenza nella leggibilità, tuttavia, può risultare complicato quando si gestiscono i join left e right come nel metodo precedente si otterrebbe qualcosa del genere:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

Quanto sopra è il vecchio modo in cui viene scritto un join sinistro in contrapposizione al seguente:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

Come puoi vedere visivamente, il modo moderno di come viene scritto lo script rende la query più leggibile. (A proposito, lo stesso vale per i giunti giusti e un po 'più complicato per i giunti esterni).

Tornando alla piastra della caldaia, non fa differenza per il compilatore SQL il modo in cui viene scritta la query in quanto li gestisce allo stesso modo. Ho visto un mix di entrambi nei database Oracle che hanno coinvolto molte persone, sia i più vecchi che i più giovani. Ancora una volta, si riduce a quanto sia leggibile la sceneggiatura e il team con cui stai sviluppando.

Nella mia esperienza, l'uso della sintassi cross-join-with-a-where-where produce spesso un piano di esecuzione danneggiato dal cervello, soprattutto se si utilizza un prodotto Microsoft SQL. Il modo in cui SQL Server tenta di stimare il numero di righe della tabella, ad esempio, è terribilmente orribile. L'uso della sintassi del join interno offre un certo controllo su come viene eseguita la query. Quindi, da un punto di vista pratico, data la natura atavica dell'attuale tecnologia di database, devi andare con l'unione interna.