- Hay más gastos generales de los que mencionaste. 20 bytes/fila podría estar cerca .
- No confíes en
SHOW TABLE STATUSpara dar "Filas", useSELECT COUNT(*) ...Fíjate cómo estuvo apagado por casi un factor de 2. - Calcule al revés:135245332480 / 3017513240 =45 bytes.
- De 45 bytes, ¿deduzco que muchas de las celdas son NULAS?
- Cada columna en cada fila tiene una sobrecarga de 1 o 2 bytes.
- El
ROW_FORMATimporta. TEXTyBLOB(etc) tienen reglas radicalmente diferentes a las de los tipos de datos simples.- Los índices toman mucho más que los 6 bytes que mencionaste (mira tus otras publicaciones ).
- La estructura BTree tiene algunos gastos generales. Cuando se carga en orden, se llena 15/16 de cada bloque (eso se menciona en algún lugar de los documentos). Después de la rotación, el rango puede llenarse fácilmente en un 50-100%; un BTree gravita al 69% de su capacidad (de ahí el 1,45 en la otra publicación).
Reservando una cantidad igual de espacio para la copia de seguridad...
- No sé si eso es lo que están haciendo.
- Si usan mysqldump (o similar), no es una fórmula segura -- el texto volcado de la base de datos podría ser significativamente mayor o menor.
- Si usan LVM, entonces tienen espacio para un volcado binario completo. Pero eso no tiene sentido debido a COW.
- (Así que me doy por vencido en la Q3.)
¿Podría el servicio en la nube estar realizando algún tipo de compresión?
