Viernes negro. WordPress + WooCommerce en un VPS. La página de inicio se carga en doce segundos, no debido al tráfico viral, sino debido a una tabla "postmeta" sin índices y con un disco MySQL de intercambio. Al mismo tiempo, el "guardado" automático nunca se restableció; El último volcado fue hace seis días. Las bases deberían haberse sentado antes de la crisis, no después de la autopsia.
MySQL en un sitio dinámico no está “instalado por el host y, por lo tanto, regulado”. Este es el corazón transaccional de sus ingresos: catálogo, pedidos, cuentas de clientes. Cuatro pilares sostienen la producción: motor en buen estado, cuentas limitadas, consultas indexadas y copias de seguridad comprobadas.
Limpiar motor y juego de caracteres
Comience verificando qué usa realmente su aplicación:
- InnoDB obligatorio para tablas de negocios: transacciones, recuperación ante fallas, claves externas.
- utf8mb4 para emojis y todos los caracteres Unicode; no el antiguo
utf8truncado a tres bytes. - Clasificación coherente en todas las tablas: evita uniones implícitas lentas.
Consulte las tablas heredadas:
MOSTRAR ESTADO DE LA TABLA DONDE Motor! = 'InnoDB';
Convierta MyISAM antes del próximo corte de energía, no el día en que un corte corrompe una tabla sin un registro de transacciones.
Cuentas y superficie de ataque
Un único usuario root en el archivo .env de WordPress o Laravel es una mala práctica común:
| Cuenta | Derechos | Uso |
|---|---|---|
usuario_aplicación | CRUD solo en app_db | PHP, WordPress, aplicación |
usuario_copia de seguridad | SELECCIONAR + BLOQUEAR o volcar herramienta | cron de copia de seguridad |
raíz | TODOS | Administración humana local, no en .env |
Ningún usuario % accesible desde Internet. Vincule MySQL al host local o a una red privada si es posible; consulte firewall VPS. Una cuenta de aplicación comprometida no debería poder "DROP DATABASE".
Rendimiento antes que hardware
Antes de actualizar el servidor, mida:
- Registro de consultas lento habilitado con un umbral de 1 a 2 segundos; analizar cada semana.
- Índice en las columnas de las cláusulas WHERE y JOIN: no hay índice en todas las columnas.
- Grupo de buffer InnoDB en aproximadamente el 70% de la RAM MySQL dedicada en un VPS solo de base de datos.
- Caché de consultas — obsoleto en MySQL 8; no intentes reactivarlo.
En WordPress, active un caché de objetos (Redis) después de limpiar el SQL, no antes. Un caché que oculta una consulta durante doce segundos pospone el problema, no lo soluciona.
Copias de seguridad y recuperación comprobadas
Una copia de seguridad que nunca ha sido probada no es una copia de seguridad:
- mysqldump cifrado externo diario + binlog si se requiere una restauración en un momento dado.
- Instantánea del disco si MySQL se ejecuta localmente en el VPS.
- Prueba de restauración trimestral — ver probar una restauración.
- Documentar la versión de MySQL del volcado versus el objetivo de restauración.
En compartido, las exportaciones pasan por el panel o un cron si SSH está disponible; verifique el tamaño máximo y las exclusiones. Compare las ofertas con MySQL administrado a través del directorio y el comparador si la alta disponibilidad se convierte en un problema.
Replicación y alta disponibilidad: solo si es necesario
Una réplica de solo lectura para informes: útil. Conmutación por error automática: complejidad operativa significativa; a menudo, MySQL administrado es más racional. No realice réplicas para “parecer profesional” sin un runbook de conmutación por error probado.
Durante el rediseño de una pila, evalúe también Postgres administrado: la migración vale la pena si su equipo aprovecha la oportunidad para repensar el esquema.
La cumbre: la base aguanta hasta el primer pico real
Esto es lo que el desarrollo local no revela.
Pregúnteles antes de la campaña, la migración o las ventas, no después de la primera CAÍDA accidental.
Decide y avanza sin puntos ciegos
En un día podrás sentar las bases:
- Auditar el motor MySQL, el conjunto de caracteres y las cuentas: convierta MyISAM, elimine la raíz de
.env. - Habilite el registro de consultas lentas y corrija las tres consultas más lentas.
- Automatice una copia de seguridad cifrada diaria y programe una restauración de prueba trimestral.
- Aislar MySQL en el host local o en la red privada: cierre el acceso directo a Internet.
- Compare hosts MySQL y MySQL administrados a través del directorio si la carga o el cumplimiento lo requieren.
Para conocer el marco general de las copias de seguridad, vaya a estrategia de copia de seguridad tan pronto como se implemente el volcado automático.
Preguntas frecuentes
¿MyISAM sigue siendo aceptable en 2026?
No para datos comerciales. InnoDB en todas partes: transacciones, recuperación ante fallos, claves externas. Convierta tablas heredadas antes de la próxima interrupción: MyISAM no registra transacciones.
¿Solo un usuario root de MySQL para la aplicación?
Mala práctica. Cree una cuenta de aplicación con derechos limitados (SELECCIONAR, INSERTAR, ACTUALIZAR, ELIMINAR) de forma única; reservar raíz para la administración humana local o vía bastión.
¿Mysqldump o copia de seguridad de instantáneas?
Los dos se complementan entre sí: volcado lógico portátil más instantánea de disco rápida. Pruebe la restauración: un volcado que nunca se ha restaurado no es un seguro.
¿Cuándo cambiar a MySQL administrado?
Siempre que la alta disponibilidad, la recuperación en un momento dado o las actualizaciones de seguridad estén fuera de su control, o cuando se reformule a Postgres administrado.
MySQL para un sitio dinámico: esta no es la versión que se muestra, es InnoDB, cuentas limitadas, índices y restauración comprobada antes de que la crisis le enseñe el vocabulario.