Se introdujeron métodos para optimizar MYSQL desde varios aspectos para obtener rendimiento. La optimización es una tarea compleja ya que, en última instancia, requiere una comprensión de todo el sistema. Si bien es posible realizar alguna optimización local con poco conocimiento de su sistema/aplicación, cuanto más desee optimizar su sistema, debe saberlo. También más. Por lo tanto, este capítulo intentará explicar y dar algunos ejemplos de diferentes formas de optimizar MySQL. Pero recuerde que siempre quedan ciertas formas (cada vez más difíciles) de hacerlo que son más rápidas para el sistema. La parte más importante para hacer que su sistema sea más rápido es, por supuesto, el diseño básico. También necesita saber que su sistema hará cosas como esta, y ese es su cuello de botella. Los cuellos de botella más comunes son:
Búsqueda de disco. El tiempo que tarda un disco en encontrar un dato. El tiempo promedio para un disco moderno utilizado en 1999 era generalmente inferior a 10 ms, por lo que, en teoría, podríamos buscar unas 1000 veces por segundo. Este tiempo mejora lentamente con los más nuevos. discos y es difícil de medir. La optimización de una tabla es distribuir los datos en varios discos. Los discos leen/escriben cuando están en la ubicación correcta donde necesitamos leer los datos. una transferencia de disco es como 10-20 Mb/s. Esto debe ser más fácil de optimizar porque se puede leer desde múltiples discos en ciclos de CPU paralelos. Cuando leemos datos en la memoria (o si ya están allí), necesitamos procesarlos para lograrlo. nuestros resultados Cuándo Este es el factor limitante más común cuando tenemos tablas con memoria relativamente pequeña, pero con tablas pequeñas la velocidad generalmente no es un problema. El ancho de banda de la memoria caché se convierte en un cuello de botella en la memoria cuando la CPU necesita más datos de los que cabe. en el caché de la CPU Este es un cuello de botella poco común en la mayoría de los sistemas, pero debe tenerlo en cuenta. 10.2 Ajuste del sistema/tiempo de compilación y parámetros de arranque Comenzamos con las cosas a nivel del sistema, ya que algunas de estas decisiones se toman muy temprano. En otras ocasiones, un vistazo rápido a esta sección puede ser suficiente, ya que no es fundamental para obtener una gran ganancia, pero siempre es bueno tener una idea de cuán grande es la ganancia en este nivel. ¡El sistema operativo predeterminado utilizado es importante para su uso máximo! múltiples CPU hasta cierto punto, debe usar Solaris (porque los subprocesos funcionan muy bien) o Linux (porque el núcleo 2.2 tiene muy buen soporte SMP y en máquinas de 32 bits, Linux tiene un límite de tamaño de archivo de 2G de forma predeterminada). Con suerte, esto se solucionará pronto cuando se lance el nuevo sistema de archivos (XFS). Dado que no ejecutamos MySQL en producción en muchas plataformas, le recomendamos que pruebe la plataforma que desea ejecutar antes de elegirla.
Otras sugerencias:
Si tiene suficiente RAM, puede eliminar todos los dispositivos de intercambio. Algunos sistemas operativos usarán un dispositivo SWAP en algunos casos, incluso si tiene memoria libre. Utilice la opción --skip -locking de MySQL para evitar el bloqueo externo. Funcionalidad MySQL siempre que solo se ejecute en un servidor. Solo recuerde detener el servidor (o bloquear las partes relevantes) antes de ejecutar myisamchk. En algunos sistemas, este cambio es obligatorio porque el bloqueo externo no está disponible en ningún trabajo en todos los casos. Al compilar con MIT-pthreads, la opción --skip-locking está activada (activada) de manera predeterminada porque MIT-pthreads no admite completamente MIT-pthreads en todas las plataformas. El único caso es si cuando ejecuta el servidor MySQL (no. el cliente) en los mismos datos, no puede usar --skip-locking; de lo contrario, ejecute myisamchk en la tabla sin primero vaciar o bloquear el servidor mysqld. Aún puede usar LOCK TABLES/UNLOCK TABLES, incluso si está usando --skip. -cierre.
Cómo la compilación y la vinculación afectan la velocidad de MySQL
La mayoría de las siguientes pruebas se realizaron en Linux y utilizando el punto de referencia MySQL, pero deberían dar alguna indicación para otros sistemas operativos y cargas de trabajo. Obtienes los ejecutables más rápidos cuando los vinculas con -static Usando sockets Unix Conexión a una base de datos en lugar de TCP. /IP también puede ofrecer un mejor rendimiento. En Linux, obtendrá el código más rápido al compilar con pgcc y -O6. Para compilar "sql_yacc.cc" con estas opciones, requiere alrededor de 200 M de memoria, porque gcc/pgcc requiere mucha. memoria para hacer que todas las funciones estén en línea Al configurar MySQL, también debe configurar CXX=gcc para evitar incluir la biblioteca libstdc++ (no es necesaria. Simplemente usando un mejor compilador o mejores opciones de compilador, puede obtener un 10). -30% de aceleración en su aplicación. ¡Esto es especialmente importante si compila el servidor SQL usted mismo! En Intel, debe usar, por ejemplo, pgcc o el compilador Cygnus CodeFusion. Hemos probado el nuevo compilador Fujitsu, pero aún no lo es. Lo suficientemente libre de errores como para optimizar la compilación de MySQL.
Aquí tenéis algunas hojas de medidas que hemos realizado:
Si usa pgcc con -O6 y compila algo, el servidor mysqld es un 11% más rápido que con gcc (con la versión string 99). Si vincula dinámicamente (sin -static), el resultado es un 13% más lento. Todavía se puede usar una biblioteca MySQL vinculada dinámicamente. Solo el servidor es crítico para el rendimiento. Si usa TCP/IP en lugar de sockets Unix, el resultado es un 7,5% más lento. En una Sun SPARCstation 10, gcc2.7.3 es más rápido que Sun Pro C++. 4.2 es un 13% más rápido. En Solaris 2.5.1, MIT-pthreads es entre un 8 y un 12% más lento que Solaris con subprocesos nativos en un solo procesador. Con más carga/cpus, la diferencia debería ser aún mayor. Cortesía de TcX MySQL-. La distribución de Linux está compilada con pgcc y vinculada estáticamente.
Como se mencionó anteriormente, la búsqueda de disco es un gran cuello de botella en el rendimiento. Este problema se vuelve cada vez más obvio cuando los datos comienzan a crecer, por lo que el almacenamiento en caché se vuelve imposible para bases de datos grandes, donde el acceso a los datos debe ser más o menos aleatorio. Confíe en el hecho de que necesitará al menos una búsqueda de disco para leer y varias búsquedas de disco para escribir. Para minimizar este problema, utilice discos con tiempos de búsqueda bajos para aumentar la cantidad de ejes de disco disponibles (y así reducir la sobrecarga de búsqueda). es posible vincular archivos a diferentes discos o dividir el disco. El uso de enlaces simbólicos significa que vincula simbólicamente los archivos de índice/datos del directorio de datos normal al otro disco (que también se puede dividir). veces mejor (si el disco no se usa para otras cosas). Consulte 10.2.2.1. Uso de enlaces simbólicos a bases de datos y tablas. Dividir Dividir significa que tiene muchos discos y coloca el primer bloque en un disco, el segundo bloque está en el segundo disco. , y el enésimo bloque está en el (n mod número_de_discos)ésimo disco, etc. Esto significa que si el tamaño de datos normal es menor que el tamaño de división (o perfecto (dispuesto en consecuencia), obtendrá un rendimiento ligeramente mejor. Tenga en cuenta que la división Depende mucho del sistema operativo y del tamaño de división. Por lo tanto, pruebe su aplicación con diferentes tamaños de división. Consulte 10.8 Uso de su propio punto de referencia. Tenga en cuenta que la división depende mucho del sistema operativo y del tamaño de división. los parámetros y la cantidad de discos, puede obtener una diferencia de órdenes de magnitud. Tenga en cuenta que debe elegir optimizar para acceso aleatorio o secuencial. Para mayor confiabilidad, es posible que desee utilizar raid RAID 0+ 1 (dividido + espejo). en este caso necesitarás 2*N unidades para almacenar los datos de N unidades. Si tienes el dinero, esta es probablemente la mejor opción. Sin embargo, es posible que también tengas que invertir en un software de administración de volumen para manejarlo de manera eficiente. Una buena opción es tener los datos menos importantes (que se pueden reproducir) en un disco RAID 0 y los datos realmente importantes (como información del host y archivos de registro) en discos RAID 0+ 1 o RAID N si tiene muchos. de escrituras debido a la actualización de los bits de paridad, RAID N puede ser un problema. También puede configurar los parámetros para el sistema de archivos utilizado por la base de datos. Un cambio fácil es montar el sistema de archivos con la opción noatime. el inodo que omite la actualización, y esto evitará algunas búsquedas de disco.
Puede mover tablas y bases de datos desde el directorio de la base de datos a otra ubicación y reemplazarlas con símbolos que enlacen a la nueva ubicación. Es posible que desee hacer esto, por ejemplo, moviendo una base de datos a un sistema de archivos que tenga más espacio libre. Avisos de MySQL Una tabla es un enlace simbólico, que resolverá el enlace simbólico y utilizará la tabla a la que realmente apunta. Funciona en todos los sistemas que admiten la llamada realpath() (al menos Linux y Solaris admiten realpath()). que no admiten realpath() En su sistema, no debe acceder a la tabla a través de una ruta real y un enlace simbólico al mismo tiempo. Si lo hace, la tabla será inconsistente después de cualquier actualización. MySQL no admite enlaces de bases de datos. de forma predeterminada, siempre que no establezca un enlace simbólico entre las bases de datos, todo funcionará bien. Suponga que tiene una base de datos db1 en el directorio de datos de MySQL y cree un enlace simbólico db2 que apunte a db1.
shell&> cd /ruta/a/datadir
cáscara&> ln -s db1 db2
Ahora, para cualquier tabla tbl_a en db1, también habrá una tabla tbl_a en db2. Si un hilo actualiza db1.tbl_a y otro hilo actualiza db2.tbl_a, habrá problemas. Si realmente necesita esto, utilice el siguiente código. Se debe cambiar "mysys/mf_format.c":
if (!lstat(to,&stat_buff)) /* Comprueba si es un enlace simbólico */
if (S_ISLNK(stat_buff.st_mode) && ruta real(a,buff))
Cambie el código a esto:
si (ruta real(a,buff))