Base de datos de Wordpress lenta: ¿debería cambiar a InnoDB?

Tengo un sitio de WordPress con más de 10 mil publicaciones, y las cosas comienzan a ser muy lentas cada vez que agrego y edito publicaciones. Las páginas se cargan de manera agradable y rápida para los usuarios, junto con las listas administrativas de publicaciones, pero es cuando se producen escrituras o actualizaciones que el servidor pasa al 100% de la CPU y tarda mucho tiempo (a veces más que el tiempo de espera de PHP de 60 s).

Estoy pensando que esto probablemente tenga que ver con el bloqueo de nivel de tabla de MyISAM, y estoy pensando en cambiar esto a InnoDB. ¿Cuáles son las implicaciones de hacer esto?

Algunas estadísticas:

select  - per hour ~22k
update  - per hour ~7.6k
set option  - per hour ~7k

Sé que hay muchas otras optimizaciones que puedo hacer, pero siento que esto podría tener el mayor impacto.

Gracias

Editar : He encontrado uno de los principales problemas que causan la lentitud, fue YARPP (Plugin de publicaciones relacionadas) que estaba regenerando la "relación" cada vez, y esto parecía deberse a las etiquetas 2k + que tenemos. Desactivé la opción "considerar etiquetas" y se ha acelerado considerablemente.

Además, otros complementos que regeneran cosas pueden causar este tipo de problemas, como algunos complementos de mapa de sitio XML.

Por lo tanto, mi problema inmediato está resuelto, ¡aunque aún me encantaría escuchar una buena respuesta a InnoDB vs MyISAM for Wordpress!

De hecho, me cambiaría a InnoDB. El bloqueo de tabla / bloqueo de fila ha sido discutido por muchos durante mucho tiempo. Siempre elegiría InnoDB sin dudas. Sin embargo, hay otra razón profunda para elegir InnoDB ... CACHING .

Si bien la mayoría de las personas se jactan de que MyISAM es más rápido para las lecturas, la mayoría de las personas olvidan que la gran cantidad de caché para MyISAM, que se llama caché de claves (establecida por key_buffer_size), solo almacena en caché las páginas de índice de los archivos .MYI. Nunca almacena en caché las páginas de datos. Tiene un máximo oficial de 4 GB en sistemas de 32 bits. 8 GB es el mejor máximo para 64 bits.

El InnoDB Buffer Pool almacena en caché los datos y las páginas de índice. Dependiendo del servidor que tenga, puede almacenar en caché hasta el conjunto de datos completo en la RAM. Puede ajustar InnoDB para hasta un 80% de RAM y un 10% para las conexiones de base de datos, y dejar un 10% para el sistema operativo. Esto es cierto incluso para diferentes sistemas operativos .

He recomendado estas cosas para los clientes de Drupal con un éxito maravilloso. Se aplica a Wordpress también. He proporcionado soporte DB para clientes con WordPress. Las mismas mejoras.

Siempre puede configurar la memoria para InnoDB de manera más efectiva que con MyISAM. Siempre hay una manera de modificar InnoDB para satisfacer sus necesidades de rendimiento . A medida que crecen sus datos, eventualmente se convertirá en un requisito .

InnoDB probablemente no lo ayudará: el bloqueo de nivel de página / fila ayuda a mitigar la contención, pero no parece que ese sea su problema.

Hay muchas cosas por ahí que sugieren que MyISAM es más lento que InnoDB en el escenario de blog promedio (muchas más lecturas que escrituras).

Antes de hacer un cambio, al menos debe hacer lo siguiente

• ejecute mysqltuner que le dará algunos consejos de configuración (no es infalible o todo lo sabe)
• active el registro lento de consultas, déjelo por un día más o menos, y luego comience a examinar el registro y EXPLICAR las consultas para ver qué está sucediendo

Por experiencia personal, descubrí que agregar un índice a un campo no indexado en wp_comments me ayudó enormemente en mi situación particular (períodos de comentarios en ráfagas, donde aproximadamente 10 personas podrían estar tratando de comentar al mismo tiempo), y es posible que descubra qué consultas se ejecutan lentamente y por qué pueden llevarlo a una mejor comprensión del problema, ¡y a una solución REAL!