MySQL Reference Manual for version 3.21.31. - MySQL の最大性能を得る方法は？

この結果、全ての mysqld オプションと次のようなコンフィグ可能変数のリストを得られます。

次のテストの多くは Linux 上で MySQL ベンチマークで行われました。しかし、これらは他のOSについてもいくつかの指標を与えます: Linux では、pgcc と -O6 でコンパイルした時に最速のコードを得られます。このオプションで sql_yacc.cc をコンパイルすると、gcc/pgcc は全ての関数をインラインにするために多くのメモリを必要とするので、180M のメモリが必要です。libstdc++ ライブラリの増加を避けるためには、MySQL の configure 時に CXX=gcc も設定すべきです。 -static でのリンク時に最速の実行形式を得ます。TCP/IP の代わりに Unix ソケットをデータベースへの接続に使用することも、より良い性能を与えます。 ● gcc の代わりに pgcc を使用して -O6 で全てをコンパイルすると、プログラムは gcc よりも 11% 速くなります。 ● 動的リンク(-static 無し)の場合、結果は 13% 遅くなります。 ● (localhost への接続に)Unix ソケットの代わりに TCP/IP を使用すると、結果は 7.5% 遅くなります。 ● Sun SPARCstation 10 では、gcc 2.7.3 は Sun Pro C++ 4.2 より 13% 速くなります。 ● Solaris 2.5.1 mit-pthreads は Solaris ネイティブスレッドより 8-12% 遅くなります。 TCX により配布されている MySQL-linux 配布は pgcc でコンパイルされ、静的にリンクされています。

MySQL はどのようにメモリを使用するのか？

● key_buffer は全てのスレッドで共有され、残りは必要時に割り当てられます。 ● 各接続はいくつかのスレッド空間、スタック (64K) そして接続バッファ(変数 net_buffer_length) を使用します。 ● 全てのスレッドは同じベースメモリを共有します。 ● まだ memmap されていません (圧縮テーブルは除きますが、これは別の話)。これは 4GB の 32bit メモリ空間は多くの大きなテーブルには十分大きくないためです。64bit アドレス空間を持つシステムを我々が手に入れた時、我々は memmap を通常にサポートします。 ● mysqld の起動時にキーバッファを指定できます。これは全テーブル内の全てのインデックスを FIFO ベースでバッファします (変数 key_buffer)。 ● テーブルを越えて順次スキャンを行なう各要求は、読み込みバッファを割り当てます (変数 record_buffer)。 ● ソートを行う多くの要求は、ソートバッファと一つか二つの一時ファイルを割り当てます。﹁MySQL が一時ファイルを格納する場所﹂節参照 ● 全ての結合は1パスで行なわれ、多くの結合は一時テーブルを使用せずに行なわれます。多くの一時テーブルはメモリベース(HEAP)のテーブルです。大きなレコードサイズ (= 全項目長の合計) を持つ一時テーブルまたは、BLOB を含むテーブルはディスク上に置かれます。現在の問題は、HEAP テーブルが tmp_table_size のサイズを越えると、エラー 'The table ### is full' が出ることです。将来我々は、必要時にメモリ (HEAP) テーブルをディスクベース (NISAM) テーブルに自動的に変更することにより、これを修正します。この問題を回避するため、mysqld への -O tmp_table_size=# オプションまたは SQL オプション SQL_BIG_TABLES で増加できます。﹁SET OPTION 構文﹂節参照。MySQL 3.20 では、一時テーブルの最大サイズは recordbuffer*16 でした。そのため、このバージョンを使用していると、 recordbuffer を追加する必要があります。mysqld を --big-tables で開始することで、常に一時テーブルをディスク上に格納できます。しかしこれは全ての複雑なクエリの速度に影響します。 ● 変形と演算時に使用されるほとんど全てのメモリはローカルメモリストア内で行なわれます。小さな項目に必要とされるメモリオーバーヘッドはなく、通常の遅いメモリ割り当て/解放が回避されます。メモリは予期しない大きな文字列にだけ割り当てられます(これは malloc/free で行なわれます)。 ● 各インデックスファイルは一度オープンされ、データファイルは各同時実行スレッド毎に一度オープンされます。各同時スレッドには、テーブル構造、各項目の項目構造そして 3 * (BLOB を計算しない最大行長) のサイズのバッファが割り当てられます。BLOB は5から8バイト + BLOB データの長さを使用します。 ● BLOB を持つ各テーブルでは、より大きな BLOB の読み込みでバッファは動的に拡大されます。テーブルのスキャンをする場合、割り当てられたバッファは最も大きい BLOB と同じ大きさになります。 ● 全てのユーザテーブルはキャッシュ内に保存され、FIFO として管理されます。通常、キャッシュは64個のテーブルです。テーブルが2つの実行しているスレッドで同時に使用される場合、キャッシュ内にテーブルの2つのエントリがあります。 ● mysqladmin refresh は使用されていない全てのテーブルをクローズし、使用されている全てのテーブルを、実行中スレッドが終った時にクローズするようにマークします。これは多くの使用メモリを解放するのに有効です。全てのログファイルもクローズと再オープンされます。 mysqld 実行時、ps や他のプログラムは、それが多くのメモリを使用していると報告するでしょう。これは異なったメモリアドレス上のスレッドスタックによって発生します。例えば、Solaris ps はスタック間の未使用メモリを使用メモリとして計算します。'swap -s' で有効なスワップをチェックすることでこれを確かめられます。我々は市販のメモリリーク検出プログラムで mysqld をテストしました。そのため、メモリリークは全くありません。

MySQL はどのようにインデックスを使用するか？

全てのインデックス, PRIMARY, UNIQUE そして INDEX() は B tree に格納されます。文字列は自動的に始めと終りの空白が圧縮されます。﹁CREATE INDEX 構文(互換関数)﹂節参照

どのような最適化が WHERE 節で行なわれるか？

(不完全, MySQL は多くの最適化を行う。) 遅い SELECT ... WHERE をより速くするための最初の問題は、インデックスを追加できるかどうかをチェックすることです。異なるテーブル間の全ての参照は通常はインデックスを使用して行なわれます。select で使用されるインデックスをチェックするために、EXPLAIN コマンドを使用できます。﹁EXPLAIN 構文。SELECT についての情報を得る﹂節参照。﹁MySQL はどのようにインデックスを使用するか？﹂節参照 ● 括弧の除去 (全ての不必要な括弧は削除されます) ((a AND b) AND c

OR
(((a

AND b) AND (c AND d)))) -> (a AND b) OR (a AND b AND c AND d) ● 定数の保持 (a<b AND b=c) AND a=5 -> b>5 AND b=c AND a=5 ● 定数条件の除去 (定数保持のために必要とされます)。 (b

>=5
A

ND b=5) OR (b=6 AND 5=5) OR (B=7 AND 5=6) -> B=5 OR B=6 ● インデックスに使用される全ての表現は一度だけ評価されます。 ● 一つのテーブル上の WHERE がない CONST(*) は、テーブルから直接取り出されます。これはまた同じ条件下での任意の NOT NULL 表現のためにも行われます。 ● 不当な定数表現は早く検出されます。不可能な select は 0 行を返します。 ● GROUP BY または group 関数を使用しない場合は、HAVING は WHERE とマージされます。 ● 各サブ結合についての速い WHERE 評価を得るために、また、可能な限り早くレコードをスキップするために、各サブ結合についてより簡単な WHERE が構築されます。 ● 全ての使用されるインデックスを見つけます。最小のレコードを探すインデックスを使用します。インデックスは次の場合に使用されます: =, >, >=, <, <=, BETWEEN そして、'somthing%' のように文字が最初にある LIKE。 ● 全ての AND レベルにかからないインデックスを削除します。 ● 全ての先行する index_parts 記述を持ちます。 ● index = 1 or A = 10 -> NULL (インデックスを使用できません。) ● index = 1 or A = 10 and index=2 -> index = 1 OR index = 2 ● index_part_1 = const and index_part_3 = const -> index_part_

1 =

const ● 全ての定数テーブルを読みます。定数テーブルは次です: (一) 0 または1行のテーブル。 (二) 他の定数テーブルと完全にユニークなインデックス上の定数だけを使用するテーブル。 const_table.index = constant ● const_table.index_part_1 = const_table2.column and const_table.index_part_2 = constant ● テーブルを結合するために最良の結合の組合せを見つけます。全ての可能性を試して:(。 ORDER BY または GROUP 内の全ての項目が同じテーブルからの場合は、このテーブルは結合時に最初に優先されます。 ● order 節と異なる group 節がある場合、または order か group が結合キュー内の最初のテーブルではない他のテーブルからの項目を含む場合、一時テーブルが生成されます。 ● 各テーブルで、もし可能ならば、レコードを読むために範囲インデックスを使用します。各テーブルのインデックスはクエリされ、レコードの 30% よりスパンが小さいインデックス範囲がある場合、インデックスが使用されます。そのようなインデックスが見つけられない場合、素早いテーブルの走査(quick table scan)が使用されます。 ● 各レコードが出力される前に、HAVING 節に適合するものをスキップします。

MySQL はどのようにテーブルのオープン & クローズを行なうか？

オープンテーブルのキャッシュは最大で table-cache まで大きくなります(デフォルトは 64, -O table_cahe=# で変更可能)。キャッシュが一杯になって、他のスレッドがテーブルのオープンを試みた時、または 'mysqladmin refresh' を使用した場合を除いて、テーブルはクローズされません。制限に達すると、MySQL は、キャッシュサイズに達するか、または未使用テーブルがそれ以上なくなるまで、可能な限り多くのテーブルをクローズします。これは、全てのテーブルがいくつかのスレッドによって使用される場合、キャッシュ制限よりも多くのオープンテーブルがあることを意味します。しかし、拡張テーブルは最後にクローズされます。表は最後に使用された順に従ってクローズされます。テーブルは各同時アクセスに (再び) オープンされます。これは、同じテーブルで2つのスレッドが実行されている場合、または同じクエリで(AS で)テーブルを2回アクセスする場合、テーブルは2回オープンする必要があることを意味します。最初のテーブルのオープンは2つのファイル記述子を使用し、続くテーブルの各使用は1つだけのファイル記述子を使用します。 MySQL が、テーブルがシンボリックリンクであることに気づいた場合、 symlink を解析し、代わりにその点のテーブルを使用します。これは realpath() コールをサポートする全てのシステムで働きます︵少なくとも Linux と Solaris は realpath() をサポートします！︶。realpath() をサポートしないシステム上では、symlink とテーブルを同時に使用すべきでありません！テーブルはテーブルの更新後に矛盾するでしょう。 MySQL はデフォルトではデータベースのリンクをサポートしません。データベース間のシンボリックリンクを作成しない限り、これは正常に働きます。次に示すケースは働きません:

db2->db1
db1/

本当にこれが必要な場合は、mysys/mf_format.c を変更する必要があります:

    if (!lstat(to,&stat_buff))  /* Check if it's a symbolic link */
      if (S_ISLNK(stat_buff.st_mode) && realpath(to,buff))

to
      if (realpath(to,buff))

データベース内に約千個のテーブルを生成する欠点は何？

各テーブルは実際には3つのファイルです。ディレクトリ中に多くのファイルがある場合、オープン、クローズそして生成は遅くなります。多くの異なるテーブルで select を行なう場合も、少しオーバヘッドがあります。表キャッシュが一杯になった時、オープンする必要のある全てのテーブルのため、他のものがクローズされなければならないからです。テーブルキャッシュを大きくすることで、オーバヘッドをより小さくできます。

How does MySQL lock tables?

MySQL の全てのロックはデッドロックフリーです。これは、常にクエリ開始時に一度ロックを必要とする全てを要求し、常に同じ順でテーブルをロックすることで管理されます。 MySQL が使用する WRITE ロックのロック方法は次のように働きます: テーブル上にロックがない場合 write ロックを置き、そうでなければ write ロックキューにロックを置きます。 MySQL が使用する READ ロックのロック方法は次のように働きます: テーブル上に write ロックがない場合 read ロックを置き、そうでなければ read ロックキューにロックを置きます。ロックが解放されたとき、最初に write ロックキュー内のスレッドに、その後 read ロックキュー内のスレッドにロックを与えます。これは、同じテーブルで多くの更新をする場合、select ステートメントは update がなくなるまで待たされることを意味します。同じテーブルで多くの insert と多くの select を行う場合、これを解決するには、他のテーブルに行を挿入して、たまに、その一時テーブルから全てのレコードをもう一方のテーブルに update します。これは次のコードで行えます:

LOCK TABLES real_table WRITE, insert_table WRITE
insert into real_table select * from insert_table
delete from insert_table
UNLOCK TABLES

一つのキューだけを使用するように mysys/thr_lock.c 内のロックコードを変更することもできます。この場合、write ロックは read ロックと同じ優先順位になります。これはいくつかのアプリケーションを助けます。

私のテーブルをできるだけ速く/小さく扱う方法は？

● 可能なら NOT NULL を使用してください。これは全てをより速くし、項目毎に1ビットを節約します。 ● 全ての項目はデフォルト値を持ちます。デフォルト値が容認できない時のみ、挿入してください。insert ステートメント内で timestamp または autoincrement インデックスを挿入する必要はありません。﹁最後に挿入された行のユニークIDをどのように得られるか？﹂節参照。 ● 可能ならばより小さいテーブルを得るために、より小さい INT 型を使用してください。例えば MEDIUMINT はしばしば INT よりも良いです。 ● VARCHAR 項目を持たない場合は、固定サイズレコード形式が使用されます。これはかなり速いです。しかしあいにくいくらかの領域を浪費します。﹁行形式の種類は？また VARCHAR/CHAR の使用時は？﹂節参照。 ● MySQL がクエリをより最適化するように、関連データがロードされると一度 isamchk --analyze をテーブルに対して実行してください。これは各インデックスの値を更新し、このインデックスに同じ値が平均で何行あるかを知らせます。もちろん、ユニークインデックスではこれは常に1です。 ● インデックスとインデックスに一致するデータをソートするために isamchk --sort-index --sort-records=1 を使用してください(あなたがインデックス1でのソートを望む場合)。数値順で全てのレコードを読みたいユニークインデックスをもっていれば、これはそれをより速くさせる良い方法です。 ● テーブルにデータをロードする時、LOAD DATA FROM INFILE を使用してください。これは多くの INSERT の使用よりも通常20倍速くなります。テキストファイルがサーバ上にない場合、まずそれをサーバに rcp してください。﹁LOAD DATA INFILE 構文﹂節参照。多くのインデックスを持つテーブルへデータをロードする時、次を行うことにより、もっと速度を得ることができます: ● CREATE TABLE... で mysql または perl でテーブルを作成します。 ● mysqladmin refresh を行ないます。 ● isamchk --keys-used=0 database/table_name を使用します。これは全てのインデックスの使用をテーブルから削除します。 ● LOAD DATA INFILE... でデータをテーブルに挿入します。 ● pack_isam を持っていて、テーブルを圧縮したい場合、pack_isam を実行します。 ● isamchk -r -q database/table_name でインデックスを再生成します。 ● mysqladmin refresh を行ないます。 LOAD DATA FROM INFILE と INSERT の両方について、いくらかの速度を得るための他の可能性は、キーバッファを増大することです。これは (safe)mysqld に対する -O key_buffer=# オプションで行なうことができます。例えば、多くの RAM を持っている場合、16M は良い値です :) ● 他のプログラムへのテキストファイルとしてデータをダンプする時は、 SELECT ... INTO OUTFILE を使用してください。﹁LOAD DATA INFILE 構文﹂節参照。 ● 多くの行の挿入/更新を行なう時は、テーブルへの LOCK TABLE の使用により、さらに速度を得ることができます。...FROM INFILE... と ...INTO OUTFILE... は原子的ですので、それらの使用時に L

OCK

TABLES を行なう必要はありません。﹁LOCK TABLES 構文﹂節参照。あなたがどのように行なっているかをチェックするために、isamchk -evi を .ISM ファイルに対して実行してください。

何が INSERT ステートメントの速度に影響するか？

レコードを挿入する時間は次からなります: ● 接続: (3) ● クエリのサーバへの送信: (2) ● クエリの変形: (2) ● レコードの挿入: (1 x レコードサイズ) ● インデックスの挿入: (1 x indexes) ● クローズ: (1) ここで (数字) は比例時間です。これは、テーブルのオープンにかかる初期オーバーヘッド(これは同時に動作する各クエリ毎に1回行なわれます)は考慮されていません。テーブルのサイズはインデックスの挿入を N log N で遅くします (B-tree)。挿入の高速化の一つの方法は、挿入中テーブルをロックすることです。

LOCK TABLES a WRITE;

INSERT INTO a VALUES (1,23)
INSERT INTO a VALUES (2,34)
INSERT INTO a VALUES (4,33)
INSERT INTO a VALUES (8,26)
INSERT INTO a VALUES (6,29)

UNLOCK TABLES;

主な速度差は、全ての insert でインデックスバッファが一度だけディスクにフラッシュされることです。通常は insert があるのと同じくらい多くのインデックスバッファフラッシュがあります。ロックも複数接続テストの合計時間を低くしますが、いくつかのスレッドの最大待ち時間は上がります。例えば:

thread 1 does 1000 inserts
thread 2, 3, and 4 does 1 insert
thread 5 does 1000 inserts

ロックを使用しない場合、2, 3 そして4は1と5の前に終ります。ロックを使用する場合、2,3,4 は1や5の前に終わることはおそらくありませんが、合計時間は約 40 % 速くなります。 INSERT, UPDATE そして DELETE は MySQL ではとても速いので、1行内に約5以上の inserts/updates を行なう全ての回りにロックを追加することにより、全般的により良い性能が得られます。とても多い insert を行に行なう場合、他のスレッドにそのテーブルへのアクセスを与えるために UNLOCK TABLES つづいて LOCK TABLES を間に一度 (約 1000 行ごとに) 行ないます。これでもまだ良い性能が得られます。もちろん LOAD DATA INFILE はとても速いです。

何が DELETE ステートメントの速度に影響するか？

レコードの削除時間は正確にインデックスの数に比例します。削除の速度を上げるために、インデックスキャッシュのサイズを増加できます。デフォルトのインデックスキャッシュは 1M です。より速く削除するためにはいくつかの要因によって増やすべきです (十分なメモリがあるなら 16M を試してください)。

フルスピードで動作する MySQL を得る方法は？

● 正しいオプションで mysqld を開始します。よりメモリを持っている場合は、より速度を与えます。﹁MySQL のバッファサイズの変更方法﹂節参照。 ● SELECT をより速くするためにインデックスを作成します。﹁MySQL はどのようにインデックスを使用するか？﹂節参照 ● 項目型を可能な限り能率的に最適化します。全ての項目に NOT NULL を使用します。﹁私のテーブルをできるだけ速く/小さく扱う方法は？﹂節参照 ● --skip-locking は SQL 要求間のファイルロックを無効にします。これはより大きな速度を与えますが、次の結果になります: ● isamchk でテーブルのチェック/修復を試みる前に、全てのテーブルを mysqladmin refresh でフラッシュしなければなりません。 (isamchk -d table_name はいつでも許されます)。 ● 同じデータファイルに対して2つの MySQL サーバを実行できません。両方が同じテーブルを更新しようとする場合。 MIT スレッドでコンパイルする時は --skip-locking がデフォルトです。これは全てのプラットフォームで MIT スレッドが flock() を完全にサポートしていないためです。 ● 更新が問題の場合は、更新を遅らせて、後で行の多くの更新を行なうことができます。行内で行なわれる多くの更新は、同時に一つよりもとても速くなります。 ● 問題が MIT スレッドで、FreeBSD を使用している場合、FreeBSD 3.0 (またはそれ以上) へのアップグレードが助けになります。これはソケットの使用を可能にし(現在の MIT スレッドでの TCP/IP よりも速くなります)、スレッドパッケージをさらに完成させます。

行形式の種類は？また VARCHAR/CHAR の使用時は？

MySQL は真の SQL VARCHAR() 型を持ちません。 MySQL は代わりにレコードを格納する3つの異なる方法を持ち、これを VARCHAR() のエミュレートに使用します: VARCHAR, BLOB または TEXT 項目型のどれも使用しない場合、固定行サイズが使用されます。そうでなければ、動的行サイズが使用されます。CHAR() と VARCHAR() は、アプリケーションの観点からは同じに扱われます; 両方とも、項目がアクセスされた時に、項目から終りの空白を取り除きます。テーブルに使用された形式は isamchk -d でチェックできます。 MySQL は3つの異なったテーブル形式を持ちます: (一) 固定長テーブル。 ● これはデフォルト形式です。VARCHAR(), TEXT または BLOB 項目型がテーブルにない場合に使用されます。 ● 全ての CHAR(), NUMERIC() そして DECIMAL() 項目は空白が埋められます。 ● とても速い。 ● キャッシュが簡単。 ● クラッシュ後の再構築が簡単。レコードが固定位置にあるため。 ● 多くのレコードが削除され、領域をOSに解放したいのでなければ、(isamchk で)再編成する必要はありません。 ● これは通常は動的テーブルよりも多くのディスク領域を使用します。 (二) 動的テーブル ● VARCHAR, TEXT または BLOB 項目がテーブル内に存在する時に使用されます。 ● 全ての文字列は動的です(長さが3未満の場合を除きます)。 ● 各レコードの最初には、どの項目が空 ('') または 0 (これは null 項目と同じではありません)かを示すビットマップがあります。各文字列は長さバイト+文字列で保存されます。文字列が 0 長または数値 0 の場合、ビットマップにマークされ、ディスクに保存されません。 ● 各レコードは正確に要求されたレコード領域が使用されます。レコードが大きくなると、要求された多くの断片に分割されます。 ● 通常は、固定長レコードよりも小さいディスク領域を使用します。 ● 行長を拡張する情報で行を更新する場合、行はフラグメントされます。この場合より良い性能を得るためには、時々 isamchk -r を実行する必要があります。isamchk -ei table_name をいくつかの統計のために使用します。 ● 再構築は簡単ではありません。レコードが多くの断片にあり、リンクが失われているためです。 ● 動的サイズのレコードの期待される行の長さは次です: 3 + (項目数 + 7) / 8 + (文字型列の数) + パックされた数値項目のサイズ + 文字列の長さ + (null 項目 + 7) / 8 。各リンクには6バイトのペナルティがあります。更新がレコードの拡張を引き起こす場合に、動的レコードはリンクされます。新しい各リンクは少なくとも20バイトであり、そのため次の拡張はおそらく同じリンクに行なわれます。そうでなければ他のリンクになります。いくつのリンクがあるかは isamchk -ed でチェックできます。全てのリンクは isamchk -r で削除されます。 (三) 圧縮されたテーブル: ● pack_isam ユーティリティで作成された読み込み専用テーブル。拡張 MySQL email サポートを持つ全ての顧客は、内部使用するための pack_isam のコピーの権利を与えられます。 ● 非圧縮コードが全ての MySQL 配布に存在します。pack_isam を持っていない顧客でも、pack_isam で(同じプラットフォーム上で)圧縮されたテーブルを読み込むことができます。 ● とても少ないディスク領域を使用します。最小限のディスク使用法。 ● 各レコードは圧縮されて分割されます (とても少ないアクセスオーバーヘッド) レコードのヘッダは、テーブル中で一番大きなレコードに依存して 1-3 バイトに固定されます。各項目は別々に圧縮されます。いくつかの圧縮形式は: @itemized @bullet ● 各項目に種々のハフマンテーブルがあります。 ● サフィックス空白の圧縮。 ● プレフィックス空白の圧縮。 ● 値 0 の数値は1ビットに格納される。 ● より小さい範囲で整数が使用された場合、整数項目は可能な一番小さい型で格納されます。例えば LONGLONG(8バイト)項目は、全ての値が 0-255 の範囲にあれば、TINYINT 項目として格納されます。 ● 値が可能な値の小さなセットだけならば、値は enum() に変換されます。 ● 項目は上の圧縮の組み合わせを使用します。 (四) 固定または動的長レコードを操作できます (BLOB や TEXT 項目がない場合)。 (五) isamchk で非圧縮にできます。 MySQL は異なるインデックス型をサポートできますが、通常の一つは NISAM です。これは B-tree インデックスで、インデックスファイルのサイズを荒く計算できます: 全てのキーの次の合計: (key_length+4)*0.67 (全てのキーがソート順に挿入された時、これは最悪のケースです。) 文字列インデックスは圧縮された空白で、最初のインデックス部が文字列の場合、それは圧縮された prefix でもあります。項目が 100% に満たない場合または多くの重複がある場合、これは通常インデックスファイルをより小さくします。

何故そんなに多くのテーブルをオープンするのか？

mysqladmin status を実行した時、次のようなものが得られます:

Uptime: 426 Running threads: 1 Questions: 11082 Reloads: 1 Open tables: 12

これは、あなたが6個しかテーブルを持っていない場合、いくらか惑わせます。 MySQL はマルチスレッドなので、同じテーブルで一度に多くのクエリを持てます。同じファイル上で異なる状態を持つ2つのスレッドで、問題を最小化するため、同時に動作する各スレッドのためテーブルを再びオープンします。これはいくつかのメモリとデータファイルについての一つの拡張ファイル記述子を使用します。インデックスファイル記述子は全てのスレッド間で共有されます。

back_log	MySQL が持てる未解決の接続要求の数です。これは MySQL スレッドがとても多くの接続要求をとても短い時間に得た時に、働きます。接続のチェックと新しいスレッドの開始はメインスレッドにすこし時間 (しかしとても短い)がかかります。back_log は、MySQL が瞬間的に新しい要求への回答を停止する前に、この短い時間の間にスタックできる接続数です。短い期間に多くの接続を期待する場合にだけ、これを増加する必要があります。他の言葉では、TCP/IP 接続の入力 listne キューのサイズです。UNIX システムコール listen(2) のマニュアルページに、さらに詳細があります。この変数の最大値は OS のドキュメントをチェックしてください。
join_buffer	このバッファは(インデックス無しの)完全な結合に使用されます。それは2つのテーブル間の完全な結合ごとに1回割り当てられます。インデックスの追加ができない時、より速い完全な結合を得るために、これを増加してください。通常、速い結合を得る一番言い方法は、インデックスを追加することです。
key_buffer	バッファインデックスブロック。全てのスレッドに共有されます。多くのインデックスを持つテーブルで多くの削除/挿入を行うときに、これを増加させてください。さらに速度を得るためには `LOCK TABLES` を使用してください。「`LOCK TABLES` 構文」節参照。
max_allowed_packet	一つのパケットの最大サイズ。これはメッセージバッファを必要なときにこの制限まで増大させることを許します(`net_buffer_length` に初期化されます)。これは主に間違ったパケットを見つけるために、とても大きな値が設定されます。大きな BLOB を使用している場合は、これを増加する必要があります。使用したい最大の BLOB と同じくらい大きくするべきです。
max_connections	許される同時クライアントの数。これを増加する場合は、mysqld が持つファイルディスクリプタの数を増やす必要があるでしょう。これは OS に依存しますので、OS のドキュメントを見てください。
max_join_size	max_join_size より多いレコードを触るとエラーが返ります。長い時間をかけて百万行を返すような `WHERE` なしの結合を作成するようなユーザを持っている場合にこれを設定してください。
max_sort_length	`BLOB` または `TEXT` 項目上でソートする時に使用するバイト数。
net_buffer_length	通信バッファがクエリ間でこのサイズにリセットされます。これは通常は変更すべきではありませんが、とても小さなメモリしかない場合は、これを期待されるクエリのサイズに設定してください。
record_buffer	順序スキャンを行う各スレッドが、スキャンするテーブル毎に、このサイズのバッファを割り当てます。多くの順序スキャンを行う場合は、これを増加させてください。
sort_buffer	ソートを行う必要がある各スレッドがこのサイズのバッファを割り当てます。より速い `ORDER BY` または `GROUP BY` のためにはこれを増やしてください。「MySQL が一時ファイルを格納する場所」節参照
table_cache	全てのスレッドについてのオープンテーブルの数。これを増加する場合は、オープンファイルディスクリプタの数も増加することに注意しないといけません。 MySQL はユニークテーブル毎に2つのファイルディスクリプタを必要とします。
tmp_table_size	一時テーブルがこれよりも大きい場合、`The table ### is full` エラーが生成されます。多くの先進的な `GROUP BY` クエリを行う場合は、これを増加してください。
thread_stack	各スレッドの `C` スタックの大きさ。crash-me によって検出される多くの制限がこれに依存します。デフォルトで通常は十分です。