¿La base de datos WordPress (MyISAM) es lenta, debería cambiar a InnoDB?
Tengo un sitio WordPress con más de 10k publicaciones y las cosas se están volviendo muy lentas al agregar o editar posts. Las páginas cargan rápido para los usuarios y las listas de publicaciones en el admin también, pero cuando ocurren escrituras o actualizaciones, el servidor llega al 100% de CPU y tarda mucho (a veces más que el timeout de PHP de 60s).
Creo que esto probablemente se deba al bloqueo a nivel de tabla de MyISAM, y estoy considerando cambiarlo a InnoDB. ¿Cuáles son las implicaciones de hacer esto?
Algunas estadísticas:
select - por hora ~22k
update - por hora ~7.6k
set option - por hora ~7k
Sé que hay muchas otras optimizaciones que puedo hacer, pero siento que este cambio podría tener el mayor impacto.
Gracias
Edición: Encontré uno de los principales problemas que causaba la lentitud, era YARPP (Yet Another Related Posts Plugin) que regeneraba la "relación" cada vez, y esto parecía deberse a los más de 2k tags que tenemos. Desactivé la opción "considerar tags" y ha mejorado considerablemente la velocidad.
Además, otros plugins que regeneran cosas pueden causar este tipo de problemas, como algunos plugins de mapas de sitio XML.
Así que, mi problema inmediato está resuelto, ¡aunque todavía me encantaría escuchar una buena respuesta sobre InnoDB vs MyISAM para WordPress!

Sin duda, optaría por InnoDB. El bloqueo de tablas/filas ha sido ampliamente discutido por muchos. Yo siempre elegiría InnoDB sin dudarlo. Sin embargo, hay otra razón profunda para elegir InnoDB... EL CACHÉ.
Mientras que la mayoría de la gente presume que MyISAM es más rápido para lecturas, muchos olvidan que el caché principal de MyISAM, llamado key cache (configurado por key_buffer_size), solo almacena páginas de índices de archivos .MYI. Nunca almacena páginas de datos. Tiene un máximo oficial de 4GB en sistemas de 32 bits. 8GB es el mejor máximo para sistemas de 64 bits.
El InnoDB Buffer Pool almacena en caché tanto las páginas de datos como las de índices. Dependiendo del servidor que tengas, puedes almacenar en caché todo el conjunto de datos en RAM. Puedes ajustar InnoDB para usar hasta el 80% de la RAM, dejar un 10% para conexiones de la base de datos y reservar otro 10% para el sistema operativo. Esto es válido incluso para diferentes sistemas operativos.
He recomendado estas configuraciones a clientes de Drupal con un éxito maravilloso. También se aplica a Wordpress. He brindado soporte de bases de datos a clientes con WordPress y he obtenido las mismas mejoras.
Siempre puedes configurar la memoria para InnoDB de manera más efectiva que para MyISAM. Siempre hay una forma de ajustar InnoDB para satisfacer tus necesidades de rendimiento. A medida que tus datos crezcan, eventualmente se convertirá en un requisito.

¿Algo de esto se aplica a nosotros, los simples mortales que tenemos alojamiento compartido, con nuestros archivos en un servidor y la base de datos en otro, y nuestro proveedor es un poco dudoso sobre cuántos recursos tenemos disponibles para usar? ¿Estamos ajustando el servidor desde nuestros scripts o realmente estamos ajustando el servidor?

Por supuesto que esto aplica completamente. Puedes obtener una visión más realista de los recursos al conocer los límites que el alojamiento compartido te impone. Teniendo esto en cuenta, mejorar el rendimiento de la base de datos requeriría una conversión única bien planificada para reorganizar el uso de recursos de MySQL en lugar de escalar los recursos del sistema operativo.

InnoDB probablemente no te ayudará - el bloqueo a nivel de página/fila ayuda a mitigar la contención, pero no parece que ese sea tu problema.
Hay mucha información que sugiere que MyISAM es más lento que InnoDB en el escenario promedio de un blog (muchas más lecturas que escrituras).
Antes de hacer un cambio, deberías al menos hacer lo siguiente:
- Ejecutar mysqltuner que te dará algunos consejos de configuración (aunque no es infalible ni lo sabe todo)
- Activar el registro de consultas lentas, dejarlo funcionando por un día más o menos, y luego comenzar a revisar el registro y usar EXPLAIN en las consultas para ver qué está pasando
Por experiencia personal, encontré que agregar un índice a un campo sin indexar en wp_comments ayudó enormemente en mi situación particular (períodos de comentarios intensos, donde 10 o más personas podían estar intentando comentar al mismo tiempo), y es posible que descubrir qué consultas se están ejecutando lentamente y por qué pueda llevarte a una mejor comprensión del problema, ¡y a una solución REAL!
