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

Perché la lunghezza della riga AVG è 4 volte più grande del previsto?

Ci sono molte ragioni per cui la dimensione media della riga è alta.

  • È un'approssimazione. (Ho scoperto che in genere è alto 2x-3x.) In un caso estremo, una riga nella tabella, rivendicherà 16384 byte per riga. Questo è un blocco InnoDB. Il numero di righe nella tabella è stimato . Lo spazio su disco utilizzato per le righe è esatto, ma vedi i costi generali di seguito. La dimensione media della riga è il quoziente di questi due.

  • Overhead per colonna -- 1 o 2 byte

  • Overhead per riga -- 20-30 byte -- per la gestione delle transazioni, la ricerca di righe in un blocco, ecc

  • Overhead per blocco:un certo numero di byte per blocco da 16 KB

  • Overhead per thrashing in un BTree -- min è circa 1/16 di un blocco, max è circa metà del blocco, la media è di circa il 30% dopo molte eliminazioni e/o inserimenti casuali.

  • Sovraccarico per la preallocazione di blocchi di spazio su disco (1 MB? 8 MB?)

  • Man mano che una tabella cresce dall'adattamento in un blocco, l'algoritmo di layout cambia e la percentuale di sovraccarico aumenta temporaneamente.

  • Le righe eliminate non restituiscono il loro spazio al sistema operativo, quindi la dimensione del file rimane costante, aumentando così l'apparente dimensione della riga.

  • Se non hai una PRIMARY KEY esplicita o un UNIQUE chiave che può essere promossa a PK, quindi è presente un campo inaccessibile di 6 byte (per riga) per la PK.

  • TEXT grande /BLOB e persino VARCHAR vengono memorizzati "off-record". Questo complica molto i calcoli. E dipende da quale dei 4 ROW_FORMATs tu stai usando. In alcuni casi è presente un "puntatore" di 20 byte per ciascuna di queste celle.

  • FOREIGN KEY i vincoli non si aggiungono allo spazio richiesto, tranne per il fatto che possono forzare la creazione di un indice.

  • INDEXes , diverso dalla PRIMARY KEY non sono inclusi in avg_row_length.

  • La PRIMARY KEY solitamente comporta un sovraccarico minimo nei dati Btree. Una semplice regola pratica è l'1% di sovraccarico (sopra la colonna stessa). Questo sovraccarico è costituito dai nodi non foglia di BTree.

  • Mentre una transazione InnoDB è occupata, tutte le righe modificate vengono mantenute nell'"elenco cronologia". Ciò comporta maggiori spese generali.

  • (Non del tutto correlato). COMPRESSED di InnoDB ha problemi:fornisce solo una compressione 2x circa, a differenza della tipica compressione del testo di 3x. Costa un po' di RAM a causa della necessità di avere contemporaneamente i dati compressi e non compressi nel buffer_pool (per almeno alcuni blocchi).

SHOW TABLE STATUS e il recupero da information_schema.TABLES fornisce gli stessi dati. Ci sono modi per ottenerne alcuni approfondimento della profondità del B+Tree per i dati e per ogni tabella.