Basta ya de investigar en otros sitios porque llegaste al sitio exacto, poseemos la respuesta que quieres sin problema.
Solución:
Actualizar: El motivo por el que se registra la consulta es que no utiliza un índice. El tiempo de consulta es 0, es decir, en realidad se ejecuta rápido. Puede desactivar la opción “log-queries-not-using-indexes” si no desea que se registren.
La tabla wp_options no tiene índice en carga automática (ahora debería, se agregó al esquema central de WP el 15 de agosto de 2019), 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 señaló TheDeadMedic en los comentarios, es posible que no lo haga si los valores de carga automática son mayoritariamente sí o están 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 gran mayoría de ellos están configurados en ‘no’, puede resolver el problema por ahora 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 complemento mal escrito haciendo algo sospechoso.
Me topé con la consulta mencionada en mytop ejecutándose en mi servidor hace unos días, ¡y en realidad tomó bastante tiempo (alrededor de 10 segundos) para cada consulta! Entonces, hay situaciones del mundo real en las que wp_options puede crecer hasta un tamaño problemático. En mi caso, sospecho que el complemento de almacenamiento en caché Cachify es el responsable de inflar wp_options.
Datos de este wp_options en particular:
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 sirvió de nada.
Resulta que se habían insertado alrededor de 150 opciones transitorias en la tabla, pero no se habían eliminado automáticamente.
No sé si está relacionado o no, pero estuve revisando mis archivos /var/log/apache2/access.log y noté que varios servidores de Amazon Web Services (presuntamente comprometidos) (direcciones IP que comienzan con 54. XXX y 32.XXX) había estado intentando explotar /~web-root-dir/xmlrpc.php.
Después de solucionar algunos problemas, consulté en la tabla wp_options los nombres de las opciones que contenían “transitorio”.
seleccione * de wp_options donde option_name como ‘%transitorio%’;
Uno de los campos devueltos por esta consulta es ‘option_value’ que tiene un tipo de datos de LONGTEXT. De acuerdo con 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 estaban trabajando con aquellas que contenían “transitorio”) tenían masivo cantidades de datos en el campo option_value. Mirando a través de los resultados, también vi lo que parecían intentos de inyectar comandos en el proceso wp-cron con la esperanza de que se ejecutaran durante los ciclos cron.
Mi solución fue eliminar todas las filas “transitorias”. Esto no dañará al servidor ya que las filas “transitorias” se volverán a llenar 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 nombre_opción como ‘%transitorio%’;
También agregué los superbloques /8 de la dirección IP de AWS a mi firewall (-:
Reseñas y puntuaciones del artículo
Si crees que te ha resultado útil este artículo, nos gustaría que lo compartas con otros entusiastas de la programación y nos ayudes a dar difusión a esta información.