- Es gibt mehr Overhead als Sie erwähnt haben. 20 Byte/Zeile möglicherweise nah sein .
- Vertraue
SHOW TABLE STATUSnicht um "Zeilen" anzugeben, verwenden SieSELECT COUNT(*) ...Beachten Sie, wie es um fast den Faktor 2 abweicht. - Umgekehrt berechnen:135245332480 / 3017513240 =45 Bytes.
- Aus 45 Bytes schließe ich, dass viele Zellen NULL sind?
- Jede Spalte in jeder Zeile hat 1- oder 2-Byte Overhead.
- Das
ROW_FORMATwichtig. TEXTundBLOB(usw.) haben radikal andere Regeln als einfache Datentypen.- Die Indizes benötigen viel mehr als die von Ihnen erwähnten 6 Bytes (siehe Ihr anderes Posting ).
- Die BTree-Struktur hat etwas Overhead. Wenn der Reihe nach geladen wird, sind 15/16 jedes Blocks gefüllt (das wird irgendwo in den Dokumenten erwähnt). Nach der Abwanderung kann der Bereich leicht zu 50-100 % gefüllt sein; ein BTree tendiert zu 69 % voll (daher die 1,45 im anderen Posting).
Reservieren einer gleichen Menge an Speicherplatz für die Sicherung...
- Ich weiß nicht, ob sie das tun.
- Wenn sie mysqldump (oder ähnliches) verwenden, ist es keine sichere Formel – der Text Dump der Datenbank deutlich größer oder kleiner sein kann.
- Wenn sie LVM verwenden, haben sie Platz für einen vollständigen Binär-Dump. Aber das macht wegen COW keinen Sinn.
- (Also gebe ich Q3 auf.)
Könnte der Cloud-Dienst irgendeine Art von Komprimierung durchführen?
