Mysql
 sql >> Database >  >> RDS >> Mysql

MySQL:tavolo lungo vs tavolo largo

Innanzitutto, si tratta di due diversi modelli di dati adatti a scopi diversi.

Detto questo, mi aspetto che il secondo modello sia più veloce per l'aggregazione, semplicemente perché i dati sono compressi in modo più compatto, quindi richiedono meno I/O:

  • Il GROUP BY nel primo modello può essere soddisfatto da un pieno scansiona sull'indice {size, price} . L'alternativa all'indice è troppo lenta quando i dati sono troppo grandi per stare nella RAM.
  • La query nel secondo modello può essere soddisfatta da una scansione completa della tabella. Nessun indice necessario.

Poiché il primo approccio richiede tabella + indice e il secondo solo la tabella, l'utilizzo della cache è migliore nel secondo caso. Anche se ignoriamo la memorizzazione nella cache e confrontiamo l'indice (senza tabella) nel primo modello con la tabella nel secondo modello, sospetto che l'indice sarà più grande della tabella, semplicemente perché registra fisicamente la size e ha "buchi" inutilizzati tipici per B-Trees (sebbene lo stesso sia vero per la tabella se è cluster ).

Infine, il secondo modello non prevede il sovraccarico di manutenzione dell'indice, che potrebbe influire sulle prestazioni INSERT/UPDATE/DELETE.

Oltre a ciò, puoi considerare di memorizzare nella cache SUM e COUNT in una tabella separata contenente solo una riga. Aggiorna sia SUM che COUNT tramite trigger ogni volta che una riga viene inserita, aggiornata o eliminata nella tabella principale. È quindi possibile ottenere facilmente l'AVG corrente, semplicemente dividendo SUM e COUNT.

Ma dovresti davvero misurare su quantità rappresentative di dati per essere sicuri.

Poiché nella query non è presente alcuna clausola WHERE, tutte le righe verranno scansionate. Gli indici sono utili solo per ottenere un sottoinsieme relativamente piccolo di righe della tabella (e talvolta per scansioni solo indice ). Come regola generale, se è necessario più del 10% delle righe nella tabella, gli indici non aiutano e il DBMS spesso opterà per una scansione completa della tabella anche quando gli indici sono disponibili.