Aplica a: Web Hosting y WordPress Hosting (obligatorio) · Cloud Server y Servidores Dedicados (recomendado)
Estas prácticas están orientadas a quienes administran bases de datos MariaDB con aplicaciones propias — ERP, CRM, sistemas internos, paneles de gestión o desarrollos a medida. Aplicarlas mejora el rendimiento, la estabilidad y la escalabilidad, y reduce problemas durante migraciones o cambios de infraestructura.
En planes de Web Hosting y WordPress Hosting estas reglas son obligatorias por las limitaciones del entorno compartido. En Cloud Server y Servidores Dedicados son recomendaciones, ya que el cliente tiene control total sobre el servidor.
1. Usar siempre InnoDB como motor de almacenamiento
Todas las tablas deben usar InnoDB. Es el único motor que soporta transacciones ACID, maneja correctamente la concurrencia, permite recuperación ante fallos y es requisito para replicación moderna.
Evitá: MyISAM, MEMORY y motores heredados o experimentales.
Para verificar el motor de cada tabla:
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'NOMBRE_DB';
2. Usar un único charset y collation en toda la base
No mezcles collations dentro de la misma base de datos. La combinación recomendada para MariaDB es:
Charset:
utf8mb4Collation:
utf8mb4_unicode_ci
Evitá mezclar _general_ci, _unicode_ci, _520_ci y _0900_ai_ci en la misma base. Mezclarlos genera errores de comparación, reduce el rendimiento y complica las migraciones.
3. Todas las tablas InnoDB deben tener PRIMARY KEY
Ninguna tabla InnoDB puede quedar sin clave primaria. InnoDB la necesita para funcionar correctamente — su ausencia genera problemas en replicación, riesgo de corrupción lógica y peor rendimiento general.
Si existe una columna id, usala como PRIMARY KEY. Si no existe, creala:
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY
4. Indexar columnas usadas para búsquedas y relaciones
Toda columna usada para buscar, filtrar o relacionar tablas debe tener un índice. Los casos más comunes: columnas id, columnas *_id (foreign keys lógicas), columnas usadas en WHERE, JOIN u ORDER BY frecuentes.
Sin índices adecuados, las consultas se vuelven lentas y aumenta la carga del servidor.
5. Mantener pequeñas las tablas de configuración
Las tablas de configuración central tienden a acumular parámetros obsoletos y valores grandes que se consultan en cada request. Eliminá parámetros no utilizados y evitá guardar blobs o textos grandes innecesarios en estas tablas.
6. Limpiar datos antiguos periódicamente
Realizá limpiezas regulares de logs, registros de debug, sesiones vencidas y datos temporales. La política recomendada es mantener logs por un máximo de 30 a 90 días y eliminar historial que no se use activamente.
7. Controlar módulos y extensiones antes de instalarlos
Antes de instalar cualquier módulo o extensión, verificá que cree tablas con PRIMARY KEY, que defina índices adecuados y que limpie datos antiguos automáticamente. Evitá módulos que acumulan logs indefinidamente o crean tablas sin estructura correcta.
8. Mantenimiento recomendado
Mensualmente: limpieza de datos temporales y revisión de tablas con alto crecimiento.
Trimestralmente: revisión de PRIMARY KEYs, collations e índices. Revisión de estructura antes de migraciones o cambios de servidor.