Hay muchas razones para que el tamaño de fila promedio sea alto.
-
Es una aproximación. (Descubrí que normalmente tiene una altura de 2x-3x). En un caso extremo, una fila en la tabla, reclamará 16384 bytes por fila. Ese es un bloque InnoDB. El número de filas en la tabla es estimado . El espacio en disco utilizado para las filas es exacto, pero consulte los gastos generales a continuación. El tamaño de fila promedio es el cociente de esos dos.
-
Sobrecarga por columna:1 o 2 bytes
-
Sobrecarga por fila -- 20-30 bytes -- para manejar transacciones, encontrar filas en un bloque, etc.
-
Sobrecarga por bloque:cierta cantidad de bytes por bloque de 16 KB
-
Sobrecarga por thrashing en un BTree:el mínimo es aproximadamente 1/16 de un bloque, el máximo es aproximadamente la mitad del bloque, el promedio es aproximadamente el 30% después de muchas eliminaciones y/o inserciones aleatorias.
-
Sobrecarga para preasignar fragmentos de espacio en disco (¿1 MB? ¿8 MB?)
-
A medida que una tabla crece para encajar en un bloque, el algoritmo de diseño cambia y el porcentaje de gastos generales aumenta temporalmente.
-
Las filas eliminadas no devuelven su espacio al sistema operativo, por lo que el tamaño del archivo permanece constante, lo que aumenta el aparente tamaño de fila.
-
Si no tiene una
PRIMARY KEY
explícita o unUNIQUE
clave que se puede promocionar a PK, entonces hay un campo inaccesible de 6 bytes (por fila) para el PK. -
TEXT
grande /BLOB
e inclusoVARCHAR
se almacenan "fuera de registro". Esto complica mucho los cálculos. Y depende de cuál de los 4ROW_FORMATs
Tu estas usando. En algunos casos, hay un "puntero" de 20 bytes para cada celda. -
FOREIGN KEY
las restricciones no aumentan el espacio requerido, excepto que pueden forzar la creación de un índice. -
INDEXes
, que no sea laPRIMARY KEY
no están incluidos en avg_row_length. -
La
PRIMARY KEY
normalmente implica muy poca sobrecarga en los datos BÁrbol. Una regla general simple es 1% de gastos generales (en la parte superior de la columna misma). Esta sobrecarga son los nodos que no son hojas del BTree. -
Mientras una transacción de InnoDB está ocupada, las filas modificadas se conservan en la "lista de historial". Esto genera más gastos generales.
-
(No totalmente relacionado).
COMPRESSED
de InnoDB tiene problemas:solo proporciona una compresión de 2x, a diferencia de la compresión de texto típica de 3x. Cuesta algo de RAM debido a la necesidad de tener los datos comprimidos y sin comprimir en el buffer_pool al mismo tiempo (al menos para algunos bloques).
SHOW TABLE STATUS
y obteniendo de information_schema.TABLES
da los mismos datos. Hay formas de conseguir algo información sobre la profundidad del B+Tree para los datos y para cada tabla.