MySQL の Linux-Intel バイナリおよび RPM リリースは最高速度に設定されています。弊社では常に高速で安定したコンパイラの使用を心がけています。

バイナリのリリースは -static とリンクしていますので、通常はどのバージョンのシステム ライブラリを使用しているのか心配する必要はありません。Linux Thread をインストールする必要もありません。-static とリンクしたプログラムは動的にリンクしたプログラムより少しだけ大きくなりますが、多少速く (3-5%) なっています。しかし、静的にリンクされたプログラムの一つの問題は、ユーザー定義関数 （UDF) を使用できないことです。UDF を書いたり使用する （C あるいは C++ プログラマーの場合のみ) 場合、動的リンクを使用してご自身で MySQL をコンパイルする必要があります。

バイナリ ディストリビューションの既知の問題は libc (Red Hat 4.x あるいは Slackware など) を使用した旧 Linux システムでは、ホスト名のリゾリューションに幾つかの (致命的ではない) 問題があることです。お客様のシステムが glibc2 ではなく libc を使用している場合、多分ホスト名リゾリューションおよび getpwnam() で問題に遭遇します。これは glibc (不幸にも) が、-static でコンパイルする時でさえ、いくつかの外部のライブラリに依存してホスト名リゾリューションおよび getpwent() を実装しているからです。これらの問題は 2 つの方法で明らかです。

別の解決策、それは両方の問題を解決しますが、バイナリのディストリビューションを使用しません。MySQL のソース ディストリビューション (RPM あるいは tar.gz フォーマットで) を取得しそれをインストールします。

Linux 2.2 バージョンの中には、クライアントが TCP/IP でmysqld サーバへ新たに相当数の接続をしたときに Resource temporarily unavailable のエラーが表示される場合があります。この問題は Linux には TCP/IP ソケットを閉じる時間とシステムが実際のそれを開放する間に遅延があるためです。TCP/IP のスロット数には限りがあるため、クライアントが余りにも多くの TCP/IP 接続を短時間に行うとリソース不足のエラーに遭遇します。例えば、MySQL test-connect ベンチマークを TCP/IP で実行する時にエラーが発生する場合があります。

弊社ではこの問題に関して Linux の別々のメーリング リストを使用して数回連絡を取っていますが現在までのところまだ解決策は見つかっておりません。唯一これまで分かっている 「fix」 はクライアントの接続を執拗に続けること、あるいはデータベース サーバとクライアントが同じマシンで稼動している場合、TCP/IP 接続ではなく Unix のソケット ファイル接続を使用することです。