Share
Las diferencias entre un SQL bien escrito y otro no son enormes, y en producción en un sitio de alta demanda causan serias repercusiones en el rendimiento y la fiabilidad del servicio. En esta guía, discutiré cómo escribir consultas rápidas y qué factores contribuyen a hacer que se ejecuten lentamente..
Hoy se habla mucho sobre Big Data y las nuevas tecnologías. NoSQL y las soluciones basadas en la nube son excelentes, pero una gran cantidad de software web popular (como WordPress, phpBB, Drupal, VBulletin Forum, etc.) todavía se ejecuta en MySQL. La migración a estas nuevas soluciones puede no ser tan simple como simplemente optimizar la configuración que ya tiene en producción. Además, el rendimiento de MySQL es muy bueno, especialmente la versión de Percona..
No cometa el error común de lanzar más y más poder de cómputo para enfrentar el problema de las consultas lentas y las altas cargas de servidores, en lugar de abordar los problemas subyacentes de la raíz. Agregar potencia de CPU, SSD o RAM es una forma de optimización si lo desea, pero no es de lo que hablaré aquí. Además, sin un sitio optimizado, a medida que crezca con el hardware, los problemas se multiplicarán de manera exponencial. Así que no es una solución sólida a largo plazo..
Ser bueno en SQL es siempre una herramienta vital para un desarrollador web, y con la solución a menudo tan simple como agregar un índice o modificar ligeramente la forma en que se usa la tabla, realmente ayuda saber cómo usar bien su RDBMS. En este caso, nos estamos centrando en una popular base de datos de código abierto que se usa a menudo junto con PHP, y es MySQL..
Desarrolladores web, arquitectos de bases de datos / DBA y administradores de sistemas que están familiarizados con MySQL. Si no está familiarizado con MySQL como novato, lo más probable es que esta guía no tenga mucho sentido, pero intentaré mantenerla lo más informativa posible para los recién llegados a MySQL..
Recomiendo probar los pasos proporcionados en su propia base de datos MySQL (¡haga una copia de seguridad de todo primero, por supuesto!). Si no tiene ninguna base de datos para trabajar, se proporcionan ejemplos de creación de esquemas de base de datos donde corresponda.
Hacer copias de seguridad de MySQL es fácil con mysqldump utilidad de línea de comando:
bash $ mysqldump myTable> myTable-backup.sql
Puedes aprender más sobre mysqldump.
En resumen y en ningún orden de importancia, todos los siguientes factores importantes en el rendimiento de las consultas y el servidor:
Accentsconagua
Dónde cláusula (y el uso de las funciones internas de MySQL, tales como SI y FECHA por ejemplo)Ordenar por Abordaremos todas estas áreas dentro de esta guía. Además, si aún no lo está utilizando, instale Percona, que es un reemplazo directo para MySQL que traerá un gran aumento de rendimiento. Para ver un punto de referencia de Percona vs. MySQL, mira esta comparación.
MySQL usa los índices para encontrar filas con valores de columna específicos rápidamente, por ejemplo dentro de un DÓNDE. Sin un índice, MySQL debe comenzar con la primera fila y luego leer toda la tabla para encontrar las filas relevantes. Cuanto más grande sea la mesa, más cuesta esto..
Si la tabla tiene un índice para las columnas en cuestión, MySQL puede determinar rápidamente la posición a buscar en el centro del archivo de datos sin tener que mirar todos los datos. Esto es mucho más rápido que leer cada fila secuencialmente.
Cuando su lenguaje de secuencias de comandos se conecta con la base de datos, si ha configurado conexiones persistentes, podrá reutilizar una conexión existente sin tener que crear una nueva. Esto es óptimo para el uso de producción y debe estar habilitado.
Los usuarios de PHP pueden leer más en el Manual de PHP..
La forma más rápida y efectiva que he encontrado para solucionar este problema es a través de la utilización de un almacén de par clave-valor como Memcached o Redis.
Con Memcache simplemente puede almacenar en caché el contenido de su consulta con lo siguiente, por ejemplo:
"php connect ('localhost', 11211); $ cacheResult = $ cache-> get ('nombre-clave'); if ($ cacheResult) //… no es necesario consultar $ result = $ cacheResult; else //… ejecuta tu consulta $ mysqli = mysqli ('p: localhost', 'nombre de usuario', 'contraseña', 'tabla'); // anteponer p: a nombre de host para persistencia $ sql = 'SELECT * FROM posts IZQUIERDA ÚNETE información del usuario usando (UID) WHERE posts.post_type =' post '|| posts.post_type = 'article' ORDER BY column LIMIT 50 '; $ result = $ mysqli-> query ($ sql); $ memc-> set ('nombre-clave', $ resultado-> fetch_array (), MEMCACHE_COMPRESSED, 86400);
// Pase el $ cacheResult a la plantilla $ template-> assign ('posts', $ cacheResult);
?> "
Ahora el ejemplo UNIRSE IZQUIERDO la consulta solo se ejecutará una vez cada 86,400 segundos (24 horas), lo que le quitará una gran cantidad de carga al servidor MySQL y reducirá las conexiones simultáneas.
Nota: Prepend pag: a su argumento de host en MySQLi para conexiones persistentes.
Cuando sus datos se vuelven grandes o la demanda de su servicio aumenta, el pánico puede comenzar. Una solución rápida para asegurar que su servicio se mantenga en línea puede ser importante. Pero no lo recomiendo, porque la fragmentación intrínsecamente parece hacer que las estructuras de datos sean demasiado complicadas. Y como se explica muy elocuentemente en este artículo del blog de Percona., no fragmentar.
Crear esquemas de base de datos no es demasiado difícil cuando acepta algunas reglas de oro, como trabajar con las limitaciones y ser consciente de lo que será eficiente. Almacenando imágenes en la base de datos como gota los tipos de datos, por ejemplo, son altamente desalentados; almacenar un nombre de archivo en una varchar columna de tipo de datos es muy superior.
Asegurarse de que el diseño sea correcto para el uso requerido es primordial para crear su aplicación. Mantenga los datos específicos separados (por ejemplo, categorías y publicaciones) y asegúrese de que las relaciones de varios a uno o de uno a muchos se puedan vincular fácilmente con las ID. Utilizando el CLAVE EXTERNA La instalación de MySQL es ideal para la contingencia de datos en cascada entre tablas.
Al construir su mesa, trate de recordar lo siguiente:
ORDEN POR en MySQL.ÚNICO tipo de índice para conjuntos de datos únicos y utilizar En actualización clave duplicada para mantener actualizada la marca de tiempo datetime o unix, por ejemplo, la última vez que se comprobó la fila.EN T Tipo de datos para números enteros. Si no especifica la longitud, MySQL calculará lo que se requiere..Para optimizar de manera efectiva, debemos analizar tres conjuntos de datos fundamentales con respecto a su aplicación:
El análisis se puede hacer de varias maneras. En primer lugar, tomaremos la ruta más directa para buscar bajo el capó de las consultas de MySQL. La primera herramienta en su caja de herramientas de optimización es EXPLIQUE. Utilizando esto en su consulta antes de la SELECCIONAR le dará la siguiente salida:
sql mysql> EXPLAIN SELECT * FROM 'wp_posts' WHERE 'post_type' = 'post'; + ---- + ------------- + ---------- + ------ + ------------ ------ + ------------------ + --------- + ------- + ------ + ------------- + | id | select_type | mesa | tipo | posibles_claves | llave | key_len | ref | filas | Extra | + ---- + ------------- + ---------- + ------ + ------------ ------ + ------------------ + --------- + ------- + ------ + ------------- + | 1 | SIMPLE | wp_posts | ref | type_status_date | type_status_date | 82 | const | 2 | Usando donde | + ---- + ------------- + ---------- + ------ + ------------ ------ + ------------------ + --------- + ------- + ------ + ------------- + 1 fila en conjunto (0,00 seg)
Las columnas enumeradas contienen información útil sobre la consulta que se está ejecutando. Las columnas a las que debes prestar mucha atención son posibles_clave y Extra.
posibles_clave mostrará los índices que el motor MySQL tiene disponibles para usar para la consulta. A veces es necesario forzar un índice para garantizar que la consulta se ejecute de la manera más rápida.
los Extra columna mostrará si un condicional DÓNDE o ORDEN POR se utilizó. Lo más importante a tener en cuenta es si Utilizando Filesort aparece Considere el siguiente ejemplo:
sql EXPLAIN SELECCIONAR main_text DESDE DONDE usuario = 'myUsername' && status = '1' && (status_spam_user = 'no_spam' || (status_spam_user = 'neutral' && status_spam_system = 'neutral')) ORDER BY datum DESC LIMIT 6430, 10
Este tipo de consulta puede llegar al disco debido a la condición condicional, lo que ocurre si observamos el EXPLIQUE:
sql id select_type tipo de tabla possible_keys key key_len ref rows Extra 1 SIMPLE posts ref index_user, index_status index_user 32 const 7800 Usando dónde; Usando el archivo de archivos
Así que esta consulta tiene la posibilidad de usar dos índices y actualmente está golpeando el disco debido a la Usando el archivo de archivos en el Extra.
Qué Utilizando Filesort Está haciendo está definido aquí desde el manual de MySQL:
“MySQL debe hacer un pase adicional para descubrir cómo recuperar las filas en orden ordenado. La clasificación se realiza pasando por todas las filas según el tipo de unión y almacenando la clave de clasificación y el puntero a la fila para todas las filas que coincidan con la cláusula WHERE. Las claves se ordenan y las filas se recuperan en orden ordenado ".
Este pase adicional ralentizará su aplicación y debe evitarse a toda costa. Otro crucial Extra resultado a evitar es Usando temporal, lo que significa que MySQL tuvo que crear una tabla temporal para la consulta. Obviamente, este es un uso horrible de MySQL y debe evitarse a toda costa, a menos que no pueda optimizar más debido a los requisitos de datos. En este caso, la consulta debe almacenarse en caché en Redis o Memcache y no ser ejecutada por los usuarios..
Para solucionar el problema con Utilizando Filesort debemos asegurarnos de que MySQL use un ÍNDICE. Tiene varios posibles_clave para elegir, pero MySQL solo puede usar un índice en la consulta final. Aunque los índices pueden ser compuestos de varias columnas, la inversa no es cierta, aunque puede proporcionar sugerencias al optimizador de MySQL sobre los índices que ha creado..
El optimizador de MySQL usará estadísticas basadas en las tablas de consultas para seleccionar el mejor índice para el alcance de la consulta. Lo hace basándose en la lógica estadística de su optimizador incorporado, aunque con opciones múltiples, esto no siempre puede ser correcto sin insinuaciones. Para asegurarse de que se utiliza (o no se utiliza) la clave correcta, utilice el INDICE DE FUERZA, INDICE DE USO y IGNORE INDEX palabras clave en su consulta. Puede leer más sobre sugerencias de índices en el manual de MySQL.
Para mirar las teclas de la mesa, use el comando MOSTRAR INDICE.
Puede especificar varias sugerencias para que las utilice el optimizador, por ejemplo:
sql SELECT * FROM table1 USE INDEX (col1_index, col2_index) DONDE col1 = 1 AND col2 = 2 AND col3 = 3;
Corriendo un EXPLIQUE le mostrará qué índice se utilizó en el resultado final. Así que para arreglar el ejemplo anterior agregaremos el INDICE DE USO como tal
sql EXPLICAR SELECCIONAR main_text DESDE EL USO ÍNDICE (index_user) DONDE usuario = 'myUsername' && status = '1' && (status_spam_user = 'no_spam' || (status_spam_user = 'neutral' && status_spam_system = 'neutral')) ORDER BY datum DESC Límite 6430, 10
Ahora que MySQL tiene el index_status De la tabla a usar, la consulta es fija..
sql id select_type tipo de tabla possible_keys key key_len ref rows Extra 1 SIMPLE posts ref index_user, index_status index_user 32 const 7800 Usando donde
Junto a EXPLIQUE es el DESCRIBIR palabra clave. Con DESCRIBIR Puede ver la información de una tabla de la siguiente manera:
sql mysql> DESCRIBIR Ciudad; + ------------ + ---------- + ------ + ----- + --------- + - -------------- + | Campo | Tipo | Nulo | Llave | Predeterminado | Extra | + ------------ + ---------- + ------ + ----- + --------- + - -------------- + | Id | int (11) | NO | PRI | NULL | auto_increment | | Nombre | char (35) | NO | | | | | País | char (3) | NO | UNI | | | | Distrito | char (20) | Si | MUL | | | | Poblacion | int (11) | NO | | 0 | | +------------+----------+------+-----+---------+----------------+
Se crean índices en MySQL con el Crear índice sintaxis. Hay algunos sabores de índice. TEXTO COMPLETO se utiliza para fines de búsqueda de texto completo, y luego está la ÚNICO Tipo para asegurar que los datos se mantienen únicos.
Para agregar un índice a su tabla, use la siguiente sintaxis, por ejemplo:
sql mysql> CREATE INDEX idx_start_of_username ON 'users' (nombre de usuario (10));
Esto creará un índice en la tabla. usuarios, que utilizará las primeras 10 letras de la columna de nombre de usuario, que es un tipo de datos varchar.
En este caso, cualquier búsqueda que requiera DÓNDE ordenar en el nombre de usuario con la coincidencia en los primeros 10 caracteres sería lo mismo que una búsqueda de toda la tabla.
Los índices tienen un gran efecto en la velocidad que se tarda en devolver los datos de la consulta. El simple hecho de configurar una clave principal y un índice único generalmente no es suficiente. Las claves compuestas son donde el nicho de sintonía real se encuentra en MySQL, y la mayoría de las veces, esto requiere un control A / B EXPLIQUE.
Por ejemplo, si necesitamos hacer referencia a dos columnas dentro de nuestro DÓNDE condicional, una clave compuesta sería ideal.
sql mysql> CREATE INDEX idx_composite ON usuarios (nombre de usuario, activo);
Aquí esta clave se está creando en el nombre de usuario columna del ejemplo anterior y la columna activo, un ENUM Tipo de datos que indica si la cuenta de usuario está activa. Así que ahora al consultar los datos para DÓNDE el nombre de usuario es válido y la cuenta es activo = 1, el conjunto de datos ahora está optimizado para manejar esto mejor.
Habilite el perfilado para echar un vistazo más de cerca a sus consultas de MySQL. Esto se puede hacer en tiempo de ejecución a través de Establecer perfil = 1, y luego ejecutando su consulta y mirando el resultado de mostrar perfiles.
Con la DOP, aquí hay un fragmento de código que hace precisamente eso:
"php $ db-> query ('set profiling = 1'); $ db-> query ('seleccione encabezado, cuerpo, etiquetas de publicaciones'); $ rs = $ db-> query ('mostrar perfiles'); $ db-> query ('set profiling = 0'); // Deshabilitar el perfil después de ejecutar la consulta
$ registros = $ rs-> fetchAll (DOP :: FETCH_ASSOC); // Obtener los resultados del perfil
$ errmsg = $ rs-> errorInfo () [2]; // Atrapa cualquier error aquí "
Si no está utilizando DOP, puede hacer lo mismo con mysqli como tal
"php $ db = new mysqli ($ host, $ username, $ password, $ dbname);
$ db-> query ('set profiling = 1'); $ db-> consulta ('seleccionar encabezado, cuerpo, etiquetas de publicaciones'); if ($ result = $ db-> query ("SHOW profiles", MYSQLI_USE_RESULT)) while ($ row = $ result-> fetch_row ()) var_dump ($ row); $ result-> close ();
if ($ result = $ db-> query ("mostrar perfil para la consulta 1", MYSQLI_USE_RESULT)) while while ($ row = $ result-> fetch_row ()) var_dump ($ row); $ result-> close ();
$ db-> query ('set profiling = 0'); "
Esto le devolverá los datos de perfil, que incluirán el tiempo de ejecución en el segundo valor de la matriz asociativa:
php array (3) [0] => string (1) "1" [1] => string (10) "0.00024300" [2] => string (17) "seleccionar encabezado, cuerpo, etiquetas de las publicaciones" La consulta tardó 0.00024300 segundos en completarse. Eso es lo suficientemente rápido para no preocuparse. Pero cuando los números aumentan, debemos echar un vistazo más profundo.
Como ejemplo de trabajo, conozca su aplicación. Coloque un cheque para un DEPURAR constante en el controlador de base de datos de la capa / estructura de abstracción de la base de datos de la aplicación, y luego puede iniciar la auditoría habilitando un caso de perfil y generando el resultado con un var_dump / print_r. Ahora podrá navegar y perfilar las páginas de su sitio web con facilidad.!
Para realizar una auditoría completa de sus consultas, habilite el registro. A algunos desarrolladores con los que he trabajado les preocupa que esto sea un problema de doble cara, ya que habilitar el registro afecta un poco el rendimiento, por lo que las estadísticas que registre serán un poco más bajas que en la realidad. Si bien esto es cierto, muchos puntos de referencia muestran que no hay demasiada diferencia..
Para habilitar el registro en la versión 5.1.6 de MySQL, use el log_slow_queries y puede especificar un archivo con slow_query_log_file global. Esto se puede hacer en el indicador de tiempo de ejecución así:
bash establece global log_slow_queries = 1; establecer global slow_query_log_file = /dev/slow_query.log;
Puede configurar esto persistentemente en el /etc/my.cnf o mi.ini archivo de configuración para su servidor.
bash log_slow_queries = 1; slow_query_log_file = /dev/slow_query.log;
Después de realizar este cambio, debe reiniciar el servidor MySQL, por ejemplo,. servicio mysql restart en sistemas linux.
En el nuevo MySQL 5.6.1, log_slow_queries está en desuso y slow_query_log se utiliza en su lugar. Habilitar MESA El tipo de salida permite una experiencia de depuración mucho mejor y se puede hacer de la siguiente manera en MySQL 5.6.1 y posteriores:
bash log_output = TABLE; log_queries_not_using_indexes = 1; long_query_time = 1
long_query_time Especifica el número de segundos que se clasifica una consulta lenta. El valor predeterminado es 10 y el mínimo 0. Puede tomar valores de milisegundos especificando un valor flotante; Aquí lo he puesto a 1 segundo. Así que cualquier consulta que tome más de 1 segundo se registrará en el MESA formato de salida.
Esto se registrará en el mysql.slow_log y mysql.general_log mesas dentro de MySQL.
Para deshabilitar el registro, establezca log_output a NINGUNA.
log_queries_not_using_indexes es un booleano útil que, cuando se habilita junto con el registro lento de consultas, significa que solo se registran las consultas que se espera que recuperen todas las filas.
Esta opción no siempre significa que no se utiliza ningún índice. Por ejemplo, cuando una consulta utiliza un escaneo de índice completo, esto se registrará porque el índice no limitaría el número de filas.
Habilitar el registro en un sitio de producción con tráfico casi siempre tendrá que hacerse por un período corto, mientras se monitorea la carga para garantizar que no afecte al servicio. Si está bajo una carga pesada y necesita una solución urgente, comience por solucionar el problema cuando se le solicite MOSTRAR LA LISTA DE PROCESOS o a través de la information_schema.PROCESSLIST mesa directamente, por ejemplo. seleccione * desde information_schema.PROCESSLIST;.
Registrar todas las consultas en producción puede decirle mucho y es una buena práctica para fines de investigación cuando está auditando un proyecto, pero dejarlo en funcionamiento durante días y más a menudo no le dará más datos utilizables de lo que lo haría en un máximo de 48 horas ( en promedio, al menos capturar las horas pico de uso para tener un buen vistazo a las consultas y obtener algunas ideas de frecuencia).
Nota: si ejecuta un sitio que experimenta oleadas de tráfico pico y luego períodos de poca actividad (como un sitio web de deportes durante y fuera de temporada), tenga en cuenta cómo ve el registro. No asuma que el sitio está trabajando rápido. Haz auditoria y lo más importante configura algunos gráficos.
Percona tiene algunas grandes herramientas incluidas con él, y pt-query-digest es una herramienta de línea de comandos para analizar registros de consultas, la lista de procesos o tcpdumps.
Puedes usar pt-query-digest de las siguientes maneras:
Analice un archivo * .log (generado a partir de un registro lento de consultas, por ejemplo):
bash $ pt-query-digest slow.log
Informe sobre las consultas más lentas de host1 en tiempo real (¡muy útil!):
bash $ pt-query-digest --processlist h = host1
Use tcpdump para informar las consultas más lentas de los datos del protocolo MySQL:
"bash $ tcpdump -s 65535 -x -nn -q -tttt -i cualquier -c 1000 puerto 3306> mysql.tcp.txt
$ pt-query-digest -type tcpdump mysql.tcp.txt "
Finalmente, podemos guardar los datos de consulta lenta de un host a otro para una revisión posterior. Aquí guardamos el resumen de la consulta para slow.log en host2:
bash $ pt-query-digest --review h = host2 --no-report slow.log
Para aprender a usar completamente el pt-query-digest Herramienta de Percona, lee la página del manual..
Este gráfico de operaciones de fila de InnoDB muestra las operaciones de fila que InnoDB ha realizado: actualiza, lee, elimina e inserta.
Este es un gran tema y lo abordaré lo suficiente en esta guía para que pueda comenzar con el monitoreo de MySQL. Es importante tener en cuenta que, en general, la supervisión de todos los servicios de su sitio web es ideal para saber realmente cuál es su rendimiento y usos..
Para lograrlo recomiendo configurar un RRDTool-solución basada como Cactus Con una configuración de MySQL. Obtén una plantilla para Cacti de los chicos de Percona.
Una vez que haya configurado Cacti y pueda comenzar a analizar su aplicación, deje pasar algo de tiempo para que los gráficos se puedan acumular. Después de unos días, comenzará a ver los ritmos diurno y nocturno de su tráfico y verá cuán ocupado está realmente el servidor..
Si está buscando alertas y activadores automáticos, busque la configuración de monit, un monitor proactivo de código abierto para sistemas Unix. Con monit puede crear reglas para su servidor y asegurarse de que se le avise cuando la carga aumente para que pueda detectarla mientras ocurre.
Registrar todas las consultas lentas que tardan más de un segundo en completarse puede decirnos algo, pero también saber qué consultas se están ejecutando cientos de veces es igualmente importante. Incluso si esas consultas son cortas para ejecutarse, la sobrecarga de las solicitudes altas sigue afectando al servidor.
Es por eso que mantenerse al día cuando actualiza algo y lo pone en funcionamiento es el momento más crucial para cualquier nuevo trabajo y cambio en la base de datos. Siempre tenemos una política en mis equipos para nunca sincronizar los cambios de la base de datos de nuevas funciones después de un miércoles en un proyecto en vivo. Debe hacerse al comienzo de la semana, a más tardar el martes, para que todos los equipos puedan monitorear y brindar apoyo en consecuencia..
Antes de comenzar con las nuevas consultas, debe comparar con una herramienta de prueba de carga como ab. Cuando ejecute el punto de referencia debe estar viendo el MOSTRAR LA LISTA DE PROCESOS, y también habilitar el registro y estar monitoreando con herramientas del sistema como parte superior, gratis y iostato. Este es un paso crucial antes de poner cualquier consulta nueva en una producción en vivo. Pero no es una prueba ácida al 100% porque el tráfico en vivo puede comportarse de manera muy diferente a un punto de referencia calculado.
Para comparar con ab, asegúrese de que tiene el paquete instalado, por ejemplo:
bash #centos usuarios $ sudo yum install ab #debian / ubuntu usuarios $ sudo apt-get install ab
Ahora puedes comenzar probando tu aplicación, por ejemplo:
bash $ ab -k -c 350 -n 20000 midominio.com/
los -k significa que mantener viva la conexión, y la -c 350 es el número de conexiones simultáneas, es decir, el número de personas / clientes que llegará al sitio de una vez. Finalmente, el -n 20000 es el número de solicitudes que se harán a mi-dominio.com.
Entonces, al ejecutar el comando anterior, irá a http://my-domain.com/ con 350 conexiones simultáneas hasta que se cumplan 20,000 solicitudes, y esto se hará usando el encabezado keep alive.
Una vez que el proceso finalice las 20,000 solicitudes, recibirá comentarios sobre las estadísticas. Esto le dirá qué tan bien se desempeñó el sitio bajo el estrés que le provocó al usar los parámetros anteriores. Esta es una buena manera de saber en forma automática si su consulta ha cambiado algo..
La cantidad de solicitudes y la carga del servidor tienen un gran impacto en el rendimiento, y el tiempo de consulta puede verse afectado debido a esto. En conjunto, debe habilitar el registro lento de consultas para capturar esto en producción, y como regla de desarrollo, debe asegurarse de que todas las consultas se ejecuten en fracciones de un milisegundo (0.0xx o más rápido) en un servidor inactivo.
Implementar Memcache tendrá un impacto dramático en sus requisitos de carga y se utilizará para descargar seriamente los recursos que se estaban utilizando para procesar las consultas. Asegúrese de que está utilizando Memcached Efectivamente y evalúe su aplicación con un caché activo (precargado con valores) frente a uno frío.
Para evitar salir a la producción con una memoria caché vacía, una secuencia de comandos de precarga es una buena manera de garantizar que se leerá la memoria caché y no recibirá una gran cantidad de solicitudes todas al mismo tiempo cuando regresa de un tiempo de inactividad debido a fallas en exceso de capacidad.
Habiendo habilitado el registro, ahora has encontrado algunas consultas lentas en tu aplicación. ¡Vamos a arreglarlos! A modo de ejemplo, demostraré varios problemas comunes con los que se encontrará y la lógica para solucionarlos..
Si aún no ha encontrado ninguna consulta lenta, entonces tal vez verifique cuál es su configuración para la long_query_time Si está utilizando el método de registro de consultas. De lo contrario, habiendo comprobado todas sus consultas con perfil (Establecer perfil = 1), haga una lista de las consultas que demoran más que fracciones de milisegundos en completarse (0.000x segundos) y comencemos en esas.
Aquí hay seis problemas comunes que encuentro al optimizar las consultas de MySQL:
ORDEN POR usando el archivador.sql mysql> explica select * from products donde products.price> 4 y products.stock> 0 ordena por nombre; + ---- + ------------- + ---------- + ------ + ------------ --- + ------ + --------- + ------ + ------ + --------------- -------------- + | id | select_type | mesa | tipo | posibles_claves | llave | key_len | ref | filas | Extra | + ---- + ------------- + ---------- + ------ + ------------ --- + ------ + --------- + ------ + ------ + --------------- -------------- + | 1 | SIMPLE | productos | Todo | NULL | NULL | NULL | NULL | 1142 | Usando dónde; Utilizando filesort | +----+-------------+----------+------+---------------+------+---------+------+------+-----------------------------+
Evitar el archivo de archivos en esto es imposible debido a la ORDEN POR nombre. No importa qué permutación de índice use, lo mejor que obtendrá es Usando dónde; Utilizando Filesort en tus Extra columna. Para optimizar esto, guarde el resultado en Memcache, o haga un pedido en la capa lógica de su aplicación.
ORDEN POR en DÓNDE y un UNIRSE IZQUIERDO ORDEN POR Tiene un peaje importante en las consultas. Por ejemplo, el siguiente es un básico UNIRSE IZQUIERDO de un productos mesa y categorías Tabla por medio de un ID entero. Cuando se elimina el pedido, también se elimina el archivo.
"sql mysql> explica los productos seleccionados. * del índice de uso de productos (idx_price) dejó unir las categorías usando (catID) donde products.price> 4 y catID = 4 ORDER BY stock ASC límite 10; + - + - + - + - - + - + - + - + - + - + - + | id | select_type | table | tipo | possible_keys | key | key_len | ref | rows | Extra | + - + - + - + - + - + - - + - + - + - + - + | 1 | SIMPLE | productos | ALL | idx_price | NULL | NULL | NULL | 986 | Using where; Using filesort | | 1 | SIMPLE | categories | const | PRIMARY | PRIMARY | 4 | const | 1 | Uso del índice | + - + - + - + - + - + - + - + - + - + - + 2 filas en conjunto (0,00 seg)
mysql> explica los productos sele
