- Има повече режийни разходи, отколкото споменахте. 20 байта/ред може бъдете близо .
- Не вярвайте на
SHOW TABLE STATUS
за да дадете "Редове", използвайтеSELECT COUNT(*) ...
Забележете как се отклони с почти коефициент 2. - Изчислете по друг начин:135245332480 / 3017513240 =45 байта.
- От 45 байта заключавам, че много от клетките са NULL?
- Всяка колона във всеки ред има 1- или 2-байта надпис.
ROW_FORMAT
има значение.TEXT
иBLOB
(и т.н.) имат коренно различни правила от простите типове данни.- Индексите отнемат много повече от 6-те байта, които споменахте (вижте друга публикация ).
- Структурата BTree има някои допълнителни разходи. Когато се зарежда по ред, 15/16 от всеки блок се запълва (това е споменато някъде в документите). След разбиване, диапазонът може лесно да бъде запълнен на 50-100%; BTree гравитира до 69% пълен (оттук и 1,45 в другата публикация).
Запазване на равно количество място за архивиране...
- Не знам дали това правят.
- Ако използват mysqldump (или подобен), това не е безопасна формула - текстът дъмпът на базата данни може да бъде значително по-голям или по-малък.
- Ако използват LVM, тогава имат място за пълен двоичен дъмп. Но това няма смисъл заради КРАВА.
- (И така, отказвам се от Q3.)
Възможно ли е облачната услуга да извършва някакъв вид компресия?