MySQL Shell dumpInstance の仕組みと8.0.22 わいわい会
MySQL Release note でわいわい言う勉強会 8.0.22 でLTしてきました。
MySQL Shell の dumpInstance の仕組み
MySQL Shell のバックアップ機能 dumpInstance がどのようにして、一貫性のあるバックアップを実現しているか説明しました。
8.0.21 までは FLUSH TALBES WITH READ LOCK を利用してロックをかける方式のみでしたが、
8.0.22 以降では、FTWRLが使えない場合は、LOCK TABLES を代替として利用するようになっています。
これで、Amazon RDSなどFTWRLが使えない環境でも、一貫性のあるバックアップが取れるようになりました。 このあたりは、@atsuizo さんも解説されています。
実は、MySQL Shell 8.0.22 時点ではバグがあって、一貫性のあるバックアップが取れないときがあります（追記：このバグは MySQL Shell 8.0.23 で修正済みです） この件はバグレポートを上げています。詳細は以下のエントリーに書いています。
サーバサイド Prepared Statement の仕組み
8.0.22 会では、Derived Condition Pushdown Optimization、SRVレコードを使った接続の話、などなど。。。いろいろな話題が出ました。 中でも、Prepared Statement の話が印象深かったので、書き残しておきたいと思います。
みなさんは、サーバサイド Prepared Statement は使っていますか？自分は使ってません。。。 経験則ですが、アプリとDBサーバを一往復余計にする分、むしろ使うと遅くなることが多いように思います。言い換えると、MySQLのサーバサイドプリペアドステートメントではPREPARE時に生成しておける情報が少ないとも言えると思います *1
8.0.22 でこの辺りに多少改善が入ったようです（サーバサイドプリペアドステートメントを積極利用するほどの改善ではないですが、、、）
Historically, only the parse stage has been reused for each execution. With this work both the parse stage and the resolve stage will be prepared once and executed many times when prepared statements are executed. The planning stage will still be repeated for each prepared statement execution. The motivation for this work is to improve performance by repeated executions and also to simplify the code base.
https://mysqlserverteam.com/the-mysql-8-0-22-maintenance-release-is-generally-available/
プリペア時にはSQLの parse だけをやっていて、resolve と planning は EXECUTE 時に毎回やっていました。
これが、8.0.22 では parse に加えて、resolve ステージもPREPARE時に１回だけやるように改善したと。
resolve stage って何かっていうと、「オブジェクト（テーブルやら、カラムやら）が存在している確認したりするフェーズ」らしいです。
プリペアドステートメントの実装の一旦が知れて面白かったです。
8.022 のプリペアドステートメントまわりの挙動の変化は tom__bo さんや tmtms さんも解説してます。
