Performance of Cross Join

Question

Sto costruendo una pagina web dei contenuti fotografici. Per creare tutta la combinazione di contenuti, utilizzo Cross Join. Diciamo che ho la seguente tabella semplice:

Foto da tavolo

id filename
------------
1   a.jpg
2   b.jpg
3   c.jpg
4   d.jpg
5   e.jpg

Il numero di combinazione che posso fare dal tavolo è 10 e quelli lo sono

1,2
1,3
1,4
1,5
2,3
2,4
2,5
3,4
3,5
4,5

Ottengo il risultato sopra utilizzando la seguente query

    SELECT cp1.id,
           cp2.id 
      from photos as cp1 
cross join photos as cp2 
     where cp1.id < cp2.id

... e uso la seguente query per visualizzare sfide che un utente non ha visto.

    SELECT cp1.id,
           cp1.filename,
           cp2.id, 
           cp2.filename 
      from challenge_photos as cp1 
cross join challenge_photos as cp2 
     where cp1.id < cp2.id 
       and (cp1.id,cp2.id) not in ( (x1,x2), (x1,x2) ) 
       and cp1.id = something 
       and cp2.img_id != something

Finora, queste domande funzionano bene. Ogni query richiede circa 0,0002 sec (da 2300 righe) da PhpMyAdmin.

Supponiamo di avere 2000 righe nel mio tavolo. Il numero di possibili combinazioni è enorme. Avrò un problema quando ci sono molti utenti attivi sul mio sito Web?

Answer 1

Suggerirei di creare un database di test di varie dimensioni e testare la query per vedere le sue prestazioni. Facendo una query simile su una tabella di righe da 29k stavo ottenendo query 10-30 ms e numeri simili in una tabella di riga di 70k che può sembrare indicare che la query non è completamente terribile. Le domande sembrano anche essere memorizzate nella cache, il che significa che vedrai un vantaggio significativo se la tua tabella vede poche scritture e molte delle stesse domande.

C'è anche un'asimmetria significativa nella tua query di esempio: se cp1.id è piccolo stai ottenendo 100 secondi/1000 di righe mentre se è grande ne ottieni solo alcuni.

Questo è così domanda Si riferisce a una query di unione incrociata con una clausola in cui si comporta come un join interno.

Answer 2

Con il 2000, forse no. Con 200 migliaia di foto, probabilmente sì.

Un modo alternativo sarebbe quello di:

1. Costruisci una tabella di sfida con (CP1, CP2).
2. Fai un grilletto che quando viene inserita una nuova foto, nella tabella precedente vengono aggiunte nuove sfide
3. Quindi la tua query sarebbe (interiore) unirsi alla sfida e (due volte la) tabelle di sfida.

Con indici adeguati sulle tabelle, la query non avrebbe alcun problema. Mettere un limite (sul numero di sfide portate dalla query) aiuterebbe anche le prestazioni.