- Det finns mer omkostnader än du nämnde. 20 byte/rad kan vara nära .
- Lita inte på
SHOW TABLE STATUSför att ge "rader", användSELECT COUNT(*) ...Lägg märke till hur det var nästan en faktor 2. - Räkna åt andra hållet:135245332480 / 3017513240 =45 byte.
- Från 45 byte drar jag slutsatsen att många av cellerna är NULL?
- Varje kolumn i varje rad har 1- eller 2-byte overhead.
ROW_FORMATviktiga.TEXTochBLOB(etc) har radikalt andra regler än enkla datatyper.- Indexen tar mycket mer än de 6 byte du nämnde (se ditt andra inlägg ).
- BTrädstrukturen har vissa overhead. När det laddas i ordning, fylls 15/16 av varje block (det nämns någonstans i dokumenten). Efter churn kan området lätt vara 50-100% är fylld; ett BTree dras till 69 % fullt (därav 1,45 i det andra inlägget).
Reserverar lika mycket utrymme för säkerhetskopiering...
- Jag vet inte om det är vad de gör.
- Om de använder mysqldump (eller liknande), är det inte en säker formel -- texten dump av databasen kan vara betydligt större eller mindre.
- Om de använder LVM har de plats för en fullständig binär dump. Men det är inte vettigt på grund av COW.
- (Så jag ger upp på Q3.)
Kan molntjänsten göra någon form av komprimering?