Estoy bastante sorprendido de no poder ver una respuesta a esto en ninguna parte del sitio, ni en la documentación de MySQL (sección 5.2parece tener el registro bien cubierto!)
Si habilito los binlogs, veo un pequeño impacto en el rendimiento (subjetivamente), lo cual es de esperar con un poco de IO adicional, pero cuando habilito un registro de consultas general, veo un enorme impacto en el rendimiento (el doble del tiempo para ejecutar consultas, o peor), muy por encima de lo que veo con los binlogs. Por supuesto, ahora estoy registrando cada SELECCION así como cada ACTUALIZACIÓN/INSERCIÓN, pero otros demonios registran todas sus solicitudes (Apache, Exim) sin detenerse.
¿Estoy viendo simplemente los efectos de estar cerca de un "punto de inflexión" en el rendimiento cuando se trata de IO, o hay algo fundamentalmente difícil en el registro de consultas que hace que esto suceda? Me encantaría poder registrar todas las consultas para facilitar el desarrollo, pero no puedo justificar el tipo de hardware que parece que necesitaríamos para recuperar el rendimiento con el inicio de sesión de consultas generales.
Por supuesto, registro consultas lentas y hay una mejora insignificante en el uso general si desactivo esto.
(Todo esto está en Ubuntu 10.04 LTS, MySQLd 5.1.49, pero las investigaciones sugieren que este es un problema bastante universal)
Respuesta1
Los registros de consultas generales son unlotemás IO que los registros binarios. Además del hecho de que la mayoría de los servidores SQL tienen un 90% de lectura y un 10% de escritura, los registros binarios se almacenan en formato binario en lugar de texto sin formato, que utiliza menos espacio en disco. (¿Cuánto menos espacio? No estoy seguro. Lo siento.)
Hay dos aspectos por los que Apache y Exim pueden registrar cada solicitud sin un impacto significativo en el rendimiento. La primera es que registran el hecho de que se realizó una solicitud, pero lo que ponen en el registro suele ser significativamente más pequeño que la solicitud real. Una solicitud HTTP suele ser dos veces más grande que la línea que va en el registro e incluso un correo electrónico breve de texto sin formato es 10 o 20 veces más grande que la línea de registro que lo acompaña. Un correo electrónico con un archivo adjunto de 10 MB tendrá solo unas pocas líneas escritas en el registro.
La segunda parte de esto es que en una aplicación web normal normalmente hay docenas de consultas SQL asociadas con una sola página HTTP. Los correos electrónicos tienden a llegar en cantidades incluso menores que las solicitudes HTTP. Probablemente su servidor MySQL esté intentando registrar mucho más que Apache o Exim.
Mire el tamaño (sin comprimir) de sus registros generales y binarios de MySQL y de sus registros de Apache y Exim al final del día. Apuesto a que encontrará que el registro general de MySQL es el más grande por un factor de al menos 5.
Respuesta2
Para agregar a lo proporcionadorespuesta, también verá una reducción en el rendimiento si inicia sesión en el mismo dispositivo en el que residen sus almacenes de datos MySQL; si es el mismo disco, leerá y escribirá en múltiples ubicaciones todo el tiempo, lo que disminuirá la velocidad. Todo el proceso.
Esto es cierto incluso si se trata de una partición diferente en el mismo disco físico.
Si el registro se realiza en un dispositivo diferente, eso debería aliviaralgunode los problemas de desempeño.