- Ci sono più spese generali di quelle che hai menzionato. 20 byte/riga potrebbero essere vicino .
- Non fidarti di
SHOW TABLE STATUSper dare "Righe", usaSELECT COUNT(*) ...Nota come era spento di quasi un fattore 2. - Calcola nell'altro modo:135245332480 / 3017513240 =45 byte.
- Da 45 byte deduco che molte celle sono NULL?
- Ogni colonna di ogni riga ha un sovraccarico di 1 o 2 byte.
- Il
ROW_FORMATquestioni. TEXTeBLOB(ecc) hanno regole radicalmente diverse rispetto ai semplici tipi di dati.- Gli indici richiedono molto più dei 6 byte che hai citato (vedi il tuo altro post ).
- La struttura Btree ha delle spese generali. Quando viene caricato in ordine, vengono riempiti 15/16 di ogni blocco (che è menzionato da qualche parte nei documenti). Dopo l'abbandono, l'intervallo può essere facilmente riempito al 50-100%; un BTree gravita al 69% pieno (da cui l'1,45 nell'altro post).
Riservare una uguale quantità di spazio per il backup...
- Non so se è quello che stanno facendo.
- Se usano mysqldump (o simili), non è una formula sicura -- il testo dump del database potrebbe essere significativamente più grande o più piccolo.
- Se usano LVM, hanno spazio per un dump binario completo. Ma questo non ha senso a causa di COW.
- (Quindi rinuncio al terzo trimestre.)
Il servizio Cloud potrebbe eseguire una sorta di compressione?
