InnoDBのAUTO_INCREMENTが遅い問題は5.1でどう改善されたのか

MySQL5.1のGA版が出てから8ヶ月余りが経過しましたが、まだ5.0(あるいはそれ以前)をメインで使っている方も多いのではないでしょうか。5.1の何が良いのかいまいち分からないという方も多いかもしれません。そんな方にとって分かりやすい例の1つが、「5.1でInnoDBのAUTO_INCREMENT性能が大幅に改善された」という点です。私は仕事柄Web系の技術者の方と話をする機会もよくありますが、意外と知られていない改善なので(まさにトラフィックと同時接続数の多いWeb系システムのための改善なのに…)この機会に取り上げることにします。 簡単に言えば、AUTO_INCREMENTを持つテーブルに対してINSERTをするクライアント数が数十、数百と増えていった時に、従来はスループットが指数関数的に落ちてしまっていたのが、5.1では高速かつ安定するようになりました。以下にmysqlslapのI

[ryopeko]

2009年の話しなんだけどねえ

[taketyan]

AUTO_INCREMENT 時に行うロックの取得を局所化したってことかな

[chanpon0]

“同じロックを待つクライアント数が一定ライン(ソース上の定数LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK:200固定)を超えると、デッドロック扱いにして強制的にロールバックさせる”

[Kesin]

MySQL5.1でauto_incrementのパフォーマンスが改善した理由の解説

[bluerabbit]

MySQLはAUTO-INCでロックがかかりデッドロックエラーになることがある。同じロックを待つクライアント数が一定ライン(ソース上の定数LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK:200固定)を超えると、デッドロック扱いにして強制的にロールバッ

[gidooom]

5.0と5.1でINSERTの性能曲線がかなり違う。そしてデッドロックしていないのにデッドロック扱いのエラーの発生も5.1なら抑えられるという。これは5.1に上げるべきだな。。

[todesking]

InnoDBのauto_incrementメカニズム、フム～ン

[syanbi]

con_mameがチェックしてたので。前誰かからAUTO INCREMENTの速度低下についてきいたなこれ、

[abe_hn]

挿入レコード数が明確なINSERT文であれば、AUTO_INCREMENTの値取得の部分だけmutexで、それ以外は平行処理する。

[hirose31]

deadlock LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK:200