Consulta lenta para la tabla wp_options

Actualización : la razón por la que se registra la consulta es no utiliza un índice . El tiempo de consulta es 0, es decir, se ejecuta rápidamente. Puede desactivar la opción de "consultas de registro-no utilizar índices" si no desea que se registren.

La tabla wp_options no tiene índice en la carga automática, por lo que la consulta termina haciendo un escaneo completo de la tabla. En general, esa tabla no debería ser demasiado grande, por lo que no es un problema, pero supongo que de alguna manera sucedió en su caso.

Agregar un índice podría resolver el problema, pero como TheDeadMedic señaló en los comentarios, podría no ser así si los valores de carga automática son mayoría sí, o distribuidos uniformemente entre sí y no:

Primero, haz esta consulta para ver cómo se ve la distribución:

SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;

si la mayoría de ellos están configurados en "no", por ahora puede resolver el problema agregando un índice en la carga automática.

ALTER TABLE wp_options ADD INDEX ('autoload');

Sin embargo, es posible que desee llegar al fondo de por qué esa tabla se ha vuelto demasiado grande. Posiblemente algún plugin mal escrito haciendo algo sospechoso.

Me encontré con la consulta mencionada en mytop que se ejecuta en mi servidor hace unos días, ¡y en realidad tomó bastante tiempo (aproximadamente 10 segundos) para cada consulta! Así que hay situaciones del mundo real donde wp_options podría crecer hasta un tamaño problemático. En mi caso, sospecho que el complemento de almacenamiento en caché Cachify es responsable de la hinchazón de las opciones wp.

Datos de este particular wp_options:

5,309 rows
130MB of data

Como solución, agregué el índice similar a la solución publicada por Vinay Pai, que resolvió el problema sin problemas.

Mi tabla wp_options solo tenía alrededor de 235 filas de datos. Intenté indexar la tabla, pero no ayudó.

Resulta que se han insertado alrededor de 150 opciones transitorias en la tabla, pero no se han eliminado automáticamente.

No sé si está relacionado o no, pero había estado revisando mis archivos /var/log/apache2/access.log y noté que varios servidores de Servicios Web de Amazon (presumiblemente comprometidos) (a partir de las direcciones IP con 54.XXX y 32.XXX) había estado intentando explotar /~web-root-dir/xmlrpc.php.

Después de algunos problemas, consulté en la tabla wp_options los nombres de las opciones que contenían "transitorio"

seleccione * de wp_options donde option_name es como '% transient %';

Uno de los campos devueltos de esta consulta es 'option_value' que tiene un tipo de datos de LONGTEXT. Según los documentos de mySQL, un campo LONGTEXT (para cada fila) puede contener hasta 4 Gigabytes de datos.

Cuando ejecuté la consulta, algunas de las filas (recuerde que trabajaban con las que contenían "transitorias") tenían cantidades masivas de datos en el campo option_value. Mirando los resultados, también vi lo que parecían intentos de inyectar comandos en el proceso de wp-cron con la esperanza de que fueran ejecutados durante el ciclo (s) de cron.

Mi solución fue eliminar todas las filas "transitorias". Esto no perjudicará al servidor, ya que las filas "transitorias" se repoblarán automáticamente (si se supone que deben estar allí).

Después de hacer esto, el servidor volvió a responder.

Consulta para eliminar estas filas:

ELIMINAR de wp_options donde option_name es como '% transient %';

También he agregado la dirección IP de AWS / 8 superbloques a mi firewall (-: