Prefacio
Todo el mundo sabe que lo bien que se haga el sistema de consultas lentas determina directamente la eficiencia de resolver el problema de las consultas lentas. Una plataforma de gestión de bases de datos con un buen sistema de consulta lenta básicamente tiene la clave para desbloquear problemas de rendimiento. Pero hoy, la parte principal no es la plataforma, sino el lento problema de cinco estrellas del índice de rarezas visto en la plataforma.
Bueno, el Guanzi está agotado, y ve directamente al tema.
síntoma
Se encontraron varias de las siguientes consultas lentas en el registro SQL lento de la base de datos:
En nuestro gráfico de seguimiento, podemos ver que el número total de consultas lentas para períodos de tiempo variables aumenta todos los días, pero no se ven declaraciones de consulta. Esta es una situación que nunca se ha visto en los casos de optimización de consultas lentas que he encontrado. Tengo curiosidad. También estoy más emocionado, por lo que estoy decidido a analizar detenidamente este tema.
Solucionar problemas
Para solucionar este problema, lo primero que me viene a la mente es cómo reproducir este problema y cómo simular y reproducir este síntoma.
- Preparación de la simulación del cliente MySQL
- perl simular preparar
Conclusión: al igual que el cliente MySQL, el comando de administrador: Preparar también es invisible
- Preparación de la simulación PHP
- Resultados lentos de la simulación PHP
Conclusión: A través del código php, simulamos con éxito el resultado deseado.
Luego, siga, tome todo el proceso de ejecución de SQL con la misma identificación de sesión durante este período.
- MySQL abre el modo de captura de paquetes lento = 0
Conclusión: Descubrimos que el tiempo de preparación es realmente muy largo, pero la instrucción SQL se ejecuta muy rápidamente, lo cual es muy vergonzoso.
Originalmente, quería capturar paquetes para ver si podíamos verificar nuestra conjetura: la declaración de preparación es muy grande o las condiciones son muy complicadas, lo que lleva a que la preparación sea muy lenta en el lado del servidor, y la declaración de consulta también es muy simple. Entonces, en ese caso, encontramos el lado comercial y miramos juntos el método de preparación del negocio correspondiente. Resultó que el negocio usa el método php-pdo, por lo que tenemos los siguientes hallazgos:
- php-pdo dos modos de preparación
-
Preparar local $ dbh-> setAttribute (PDO :: ATTR_EMULATE_PREPARES, true); no se enviará al servidor MySQL
-
Lado del servidor prepare $ dbh-> setAttribute (PDO :: ATTR_EMULATE_PREPARES, false; enviar a MySQL Server
Descripción del sitio web oficial: http://php.net/manual/zh/pdo.prepare.php
- Verifique los dos modos de preparación
Modo de preparación del servidor (ATTR_EMULATE_PREPARES = false)
strace -s200 -f php mysql1.php trace como se muestra a continuación
En este modo, la consulta + marcador de posición se envía al servidor durante la preparación.
Modo de preparación local (ATTR_EMULATE_PREPARES = true)
strace -s200 -f php mysql1.php trace como se muestra a continuación
En este modo, la consulta no se enviará al servidor durante la preparación, sino que solo se enviará durante la ejecución. Después de confirmar con el lado comercial, utilizaron este último, es decir, modificaron el valor predeterminado. Originalmente querían mejorar el rendimiento de la base de datos, porque después del preprocesamiento, solo se deben pasar los parámetros, pero no es adecuado para nuestros escenarios comerciales. Nuestro escenario es abrir y cerrar conexiones con frecuencia, es decir, básicamente no se utiliza el preprocesamiento.
Además, el documento señaló claramente que el rendimiento de las declaraciones preparadas sería malo.
Ajuste y verificación
¿Cómo verificar si la parte comercial ha modificado la preparación a local?
Mediante la observación, se comprueba que este valor no ha cambiado, lo que indica que el ajuste ha surtido efecto.
para resumir
Ventajas de preparar
-
Prevenir la inyección de SQL
-
Mejorar el rendimiento en escenarios específicos
¿Qué es un escenario específico ? Primero vaya al servidor para usar marcadores de posición y luego envíe una solicitud directamente para completar los espacios en blanco (valores de parámetros). De esta manera, teóricamente hablando, llenas los espacios en blanco muchas veces antes de que la interpretación pueda entrar en juego.
Desventajas de preparar
-
Después de todo, preparar en el lado del servidor es costoso Cuando hay una gran cantidad de simultaneidad y preparaciones frecuentes, habrá problemas de rendimiento.
-
Otro problema que traerá el modo de preparación del lado del servidor es que la resolución de problemas y la optimización lenta son difíciles, porque en la mayoría de los casos no se puede ver la consulta real.
-
Intente configurar php-pdo en $ pdo-> setAttribute (PDO :: ATTR_EMULATE_PREPARES, true), prepárese localmente y no ejerza presión adicional sobre el servidor.
Consejo final
-
Por defecto, se debe usar la configuración predeterminada de php-pdo, y se puede usar el método de preparación local, de modo que se pueda lograr el efecto de prevenir la inyección de SQL y el rendimiento no sea mucho peor.
-
A menos que exista realmente un escenario específico mencionado anteriormente, puede considerar configurarlo en el modo de preparación del servidor, siempre que haga un buen trabajo de prueba.
Presta atención, no te pierdas
Muy bien, todos, lo anterior es todo el contenido de este artículo. Las personas que pueden ver aquí son todos talentos . Como dije antes, hay muchos puntos técnicos en PHP, porque hay demasiados, es realmente imposible de escribir, y no leerás demasiado después de escribirlo, así que lo organizaré en PDF y documentos aquí, si es necesario. lata
Haga clic para ingresar el código secreto: PHP + 「Plataforma」
Para obtener más contenido de aprendizaje, visite el excelente catálogo de tutoriales de arquitecto PHP de [Comparative Standard Factory], siempre que pueda leerlo para asegurarse de que el salario aumentará un paso (actualización continua)
El contenido anterior espera poder ayudarte . Muchos PHPers siempre encuentran algunos problemas y cuellos de botella cuando están avanzados. No hay sentido de dirección cuando escriben demasiado código comercial. No sé por dónde empezar a mejorar. He compilado información sobre esto, incluyendo Pero no se limita a: arquitectura distribuida, alta escalabilidad, alto rendimiento, alta concurrencia, ajuste del rendimiento del servidor, TP6, laravel, YII2, Redis, Swoole, Swoft, Kafka, optimización de Mysql, scripts de shell, Docker, microservicios, Nginx, etc. Muchos puntos de conocimiento, productos secos avanzados avanzados, se pueden compartir con todos de forma gratuita, y aquellos que lo necesiten pueden unirse a mi grupo de intercambio de tecnología PHP