8.0から、トランザクションのスケジューリングが新しいロジックに置き換わった、とのことなので、これについて少し調べてみました。Teamブログの以下の記事です。Performance少しググったところでは日本語での記事が見当たらなかったので、とりあえず上記記事をかいつまんで日本語にした、というところで少しは意味があるかと思って書いてます。後ろに行列を作って到着した順にリソースを獲得していきます。言い換えれば、トランザクションに重みづけや優先順位などはなく、リソースの獲得は早い者勝ち、ということです。大量のトランザクションを待たせているようなトランザクションがロック獲得の列に並んだ場合、そのトランザクションに優先的にロック獲得の権利を与えよう、という挙動をします。間接的に待たせているトランザクション、つまり、自分が待たせているトランザクションが待たせているトランザクションも含まれます。Teamブログでは、タクシー(Cab)のドライバーとバスのドライバーがコーヒーショップの列に並ぶ、という例を出しています。バスのように大量のお客さんを持っているようなドライバーと、タクシーのように少数のお客さんしかいないドライバーを比較した場合、バスのドライバーにコーヒーショップの列への割り込みを許すことで、より多くの乗客が目的地に早く到達できるようになる、ということです。先にコーヒーを受け取ることができるという点です。「小さい(他のトランザクションを待たせていない)トランザクションはいつまで経ってもロックが獲得できないのではないか?」という問題があります。一時的にロックへのエンキューをさせなくする(やや訳に自信なし)などの対策をしているそうです。理屈としてはこんなところです。これを踏まえて、実際に試してみました。※CATS発動は、待たされているトランザクションが32に到達した時だそうなので、それを踏まえての実験です。10の行のロックを取る。TRX1によって待たされる。5の行のロックを取る。TRX3によって待たされる。TRX1によって待たされる。5のロック開放待ちをしている。TRX2の方が到着したのは先。TRX3がid=10のロックを獲得。TRX2はまだ待たされている。すべてのロックが解放され、トランザクションが完結する。driver’となりました。Cabドライバーの方が後にトランザクションを実行したから。ここで、TRX4~35(バスの乗客)は32個あり、ギリギリCATSが発動する数になっていますが、これが1つ少なく31個しかトランザクションがない状態で試したところ、7でTRX1がコミットした直後にロックを獲得するのは、FIFOロジックに従い、先に到着したTRX2となりました。driver’となりました。5.7でも念のため試してみたところ、やはり7のところでTRX2(先に到着した方)にロックの権利が先に渡されました。これを知っていてどのくらい役に立つか、と言われると正直難しいですが、ロックの問題に取り組む時には知っておかないと思わぬところでハマる可能性があるかな、と思いました。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。Ushio駆け出しのMySQLエンジニア。OSSを仕事で扱っています。themehall.com。