CÓMO COMPRIMIR DATOS EN MYSQL: TÉCNICAS Y OPCIONES
En MySQL, específicamente en el motor de almacenamiento InnoDB, el formato de fila, ROW_FORMAT define cómo se almacenan físicamente los datos de las tablas en el disco. Uno de los formatos disponibles es COMPRESSED, que permite comprimir los datos de la tabla y sus índices para reducir significativamente el espacio en disco.Este formato forma parte del file format Barracuda (disponible desde MySQL 5.5/5.6) y es especialmente útil en entornos donde el almacenamiento es costoso o limitado.
¿Cómo funciona "ROW_FORMAT=COMPRESSED"?
El formato COMPRESSED combina dos características principales- Almacenamiento off-page eficiente (similar al formato DYNAMIC): Las columnas de longitud variable grandes (VARCHAR, TEXT, BLOB, etc.) se almacenan fuera de la página principal, dejando solo un puntero de 20 bytes. Esto permite que quepan más filas en cada página del índice.
- Compresión con zlib: InnoDB comprime tanto los datos de las filas como los índices utilizando el algoritmo zlib. Además, permite definir un tamaño de página comprimida más pequeño mediante el parámetro "KEY_BLOCK_SIZE".
Sintaxis básica
-- Crear tabla con compresión
CREATE TABLE mi_tabla (
id INT PRIMARY KEY,
descripcion TEXT,
contenido LONGTEXT
) ENGINE=InnoDB
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=8;-- Opcional: 1, 2, 4, 8 o 16 KB
-- Cambiar formato existente
ALTER TABLE mi_tabla
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=4;
Ventajas
- Ahorro significativo de espacio en disco (ideal para logs, historiales, datos textuales).
- Menor cantidad de I/O en disco (menos páginas que leer).
- Mejor rendimiento en discos duros tradicionales y SSDs de menor capacidad.
- Soporta prefijos de índice más largos (hasta 3072 bytes).
Desventajas e inconvenientes
- Mayor uso de CPU: Se requiere comprimir al escribir y descomprimir al leer.
- Buffer Pool menos eficiente: Las páginas comprimidas se descomprimen en memoria.
- No recomendado para tablas con mucho tráfico de escritura intensivo.
- No disponible en el tablespace del sistema (requiere file-per-table o general tablespaces).
- Las operaciones de "ALTER TABLE" pueden ser costosas en tablas grandes.
¿Cuándo usarlo?
- Cuando se tienes tablas grandes con mucho texto, JSON o datos repetitivos.
- El almacenamiento es más crítico que el CPU.
- La carga de trabajo es predominantemente de lectura.
- Se quiere reducir el tamaño de backups y el tiempo de transferencia.
¿Cuándo eivarlo?
- La tabla tiene muchas operaciones de escritura (INSERT/UPDATE intensivos).
- Necesitas el máximo rendimiento posible.
- Trabajas con datos ya muy comprimidos (imágenes, archivos binarios comprimidos, etc.).