Las siguientes notas relativas a glibc son aplicables únicamente en el caso que se desee compilar el código de MySQL. Si se está ejecutando Linux en un ordenador x86, en la mayoría de los casos será mucho mejor utilizar el binario. Quienes hacen MySQL enlazan los binarios utilizando la mejor y más actual versión de glibc que tienen disponible y con las opciones de compilación más apropiadas a fin de hacerlo apto para un servidor de uso intensivo o high-load. Para un usuario típico, o incluso en configuraciones con muchas conexiones concurrentes o tablas excediendo el límite de 2Gb, el binario provisto por MySQL AB es en la mayoría de los casos la mejor elección. Luego de leer el siguiente texto, si aún persiste la duda, hay que probar el binario para determinar si cubre las necesidades del usuario. Si no es suficiente, entonces puede intentarse una compilación propia. En tal caso MySQL AB apreciará que se le comuniquen los detalles para crear mejores binarios en el futuro.

MySQL emplea LinuxThreads en Linux. Si se utiliza una versión antigua de Linux que no tiene glibc2, se deberá instalar LinuxThreads antes de compilar MySQL. LinuxThreads puede descargarse de http://dev.mysql.com/downloads/os-linux.html.

Notar que las versiones de glibc hasta la 2.1.1 inclusive tienen un error fatal en el manejo de pthread_mutex_timedwait(), el cual es utilizado al emitir sentencias INSERT DELAYED. Se recomienda que no se use INSERT DELAYED sin antes haber actualizado glibc.

El kernel de Linux y la biblioteca LinuxThreads pueden manejar por defecto un máximo de 1024 subprocesos. Si se planea gestionar más de 1000 conexiones simultáneas, se necesitarán algunos cambios en LinuxThreads:

Hay otro problema que afecta enormemente el rendimiento de MySQL, especialmente en sistemas SMP (multiprocesamiento simétrico, por sus siglas en inglés). La implementación de mutex en LinuxThreads en glibc 2.1 es muy pobre para programas con muchos subprocesos que mantengan el mutex sólo por un corto tiempo. Esto produce un resultado paradójico: si se enlaza MySQL con LinuxThreads sin modificar, el quitar procesadores de un sistema SMP realmente mejora el rendimiento de MySQL en muchos casos. MySQL AB ha creado un parche disponible para glibc 2.1.3 para corregir este comportamiento (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).

Con glibc 2.2.2, MySQL utiliza el mutex adaptable, lo cual es mucho mejor inclusive que glibc 2.1.3 con parche y todo. Hay que estar al tanto, sin embargo, de que bajo ciertas condiciones, el código de exclusión mutua (mutex) actual emplea con demasiada frecuencia los spinlocks (bucles de programa que ciclan constantemente esperando por una condición), lo cual repercute en las prestaciones de MySQL. La probabilidad de que esto ocurra se puede reducir dando al proceso mysqld la máxima prioridad. MySQL AB también ha logrado corregir el comportamiento relativo a los spinlocks con un parche, que puede descargarse desde http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch. Este combina la corrección del uso excesivo de spinlocks, máximo número de procesos, y la capacidad de la pila, todo en uno. Se lo deberá aplicar en el directorio linuxthreads con patch -p0 </tmp/linuxthreads-2.2.2.patch. Es de esperar que sea incluido de alguna forma en futuras versiones de glibc 2.2. De cualquier modo, si enlaza con glibc 2.2.2, aún será necesario corregir STACK_SIZE y PTHREAD_THREADS_MAX. Es de esperar que los valores por defecto de éstos sean llevados en el futuro a un número más aceptable para configuraciones MySQL de altas prestaciones, de modo que los comandos necesarios para recompilarlo se reduzcan a ./configure; make; make install.

Se recomienda que se usen estos parches para producir una versión estática, especial, de libpthread.a y emplearla solamente para enlazado dinámico con MySQL. Se sabe que los mencionados parches son seguros para MySQL y mejoran significativamente su rendimiento, pero no se puede decir nada acerca de sus efectos sobre otras aplicaciones. Enlazar otras aplicaciones que requieran LinuxThreads con la versión estática parcheada o hacer una versión mixta e instalarla en el sistema, es por cuenta del usuario y a su riesgo.

Si se experimenta cualquier problema extraño durante la instalación de MySQL, o algunas utilidades comunes se congelan, es muy probable que esté relacionado con las bibliotecas o el compilador. Si este es el caso, utilizar el binario de MySQL AB resolverá el problema.

Si el usuario compila sus propios programas cliente, es posible que vea los siguientes errores en tiempo de ejecución:

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

Este problema puede evitarse de alguna de estas maneras:

Si se emplea el compilador Fujitsu (fcc/FCC), se puede tener algún problema al compilar MySQL porque los ficheros de cabecera de Linux están muy orientados a gcc. La siguiente línea de configure debería funcionar con fcc/FCC:

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
    -DCONST=const -DNO_STRTOLL_PROTO" \
CXX=FCC CXXFLAGS="-O -K fast -K lib \
    -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \
    -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
    '-D_EXTERN_INLINE=static __inline'" \
./configure \
    --prefix=/usr/local/mysql --enable-assembler \
    --with-mysqld-ldflags=-all-static --disable-shared \
    --with-low-memory