sql >> Base de Datos >  >> RDS >> Mysql

¿Por qué la longitud de la fila AVG es 4 veces más grande de lo esperado?

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 un UNIQUE clave que se puede promocionar a PK, entonces hay un campo inaccesible de 6 bytes (por fila) para el PK.

  • TEXT grande /BLOB e incluso VARCHAR se almacenan "fuera de registro". Esto complica mucho los cálculos. Y depende de cuál de los 4 ROW_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 la PRIMARY 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.