The latest from the MySQL community

TL;DR

• 要はこれ
  • 日々の覚書: HeatWave MySQLがどれくらいVanilla MySQL GPL版と同じくらいか考える旅 / performance_schema編
  • MySQL :: MySQL 26.10 Reference Manual :: 7.5.11 Health Monitor Component

MySQL 26.10.0で 商用版MySQL MySQL HeatWave(クラウド版)からバックポートされた機能。
インストール自体は簡単。

mysql2610 10> INSTALL COMPONENT 'file://component_health_monitor';
Query OK, 0 rows affected (0.402 sec)

これだけで …

TL;DR

• Kimi-K2.7-Codeに書いてもらったソルト固定でcaching_sha2_passwordの値を計算してもらうスクリプト
• MySQL 8.0でおなじみの caching_sha2_password はユーザー作成時にソルトをランダムに作成してその時点の設定値(ラウンド)でストレッチするので同じパスワードで CREATE USER しても同じ authentication_string にはならない
  • それが良いところではあるはずなんだけれども
  • 逆を言えば、その辺りさえ固定すれば …

これはなに 話題の strataを手元のマシンにもインストールしてみたので、「こんなこともできるのかな」とお試しでやってみたものを公開してみるものです。 内容についての正確性は保証しません（基本的には最新情報を検索して、そこからまとめてくれているので大嘘は行っていない感じではあります）。 一回やってみただけなので、今後継続するわけではありません（気が向いたらやるかも）。 なにがすごいって、「はてな記法で書いて」とお願いして出てきたものをそのままここに貼ってるだけなんです！ もうこのレベルで出力してくれる。 - MySQL のこの10日間（2026-09-28〜10-08） 対象期間: 2026…

MySQL 8.0.22とそれ以降で使える ALTER DATABASE .. READ ONLY = 1 、1mysqldプロセスに1スキーマで運用することが多かったのであんまりメリットを感じてなかった( SET GLOBAL super_read_only = ON でいいじゃん ) けどなんか使いどころに出会ったのでメモ。

大前提として、 1mysqldプロセスに1スキーマ でないこと（当たり前）がある。

これ個人的には「ベストプラクティスは1mysqldプロセスに1スキーマ」だと思っていて、その方が権限の管理もやりやすい（MySQLの権限には「グローバルスコープ」「データベース(スキーマ)スコープ」「テーブルスコープ」(ほぼ例外としての「カラムスコープ」)があるけど、 …

 2025年5月から行っていた、8.0以降の性能回復活動(MySQL-RP)は、遂に現役バージョンの8.4に到達し、RP-8.4は、RP-8.0と大体同等の性能を確保できました。（とはいえ、まだ一部怪しいところはありますが、性能は十分。）

 8.4はLTSとはいえ現役バージョンなので、MySQL-RPへのソースコードマージのコストとリスクを減らすため、RP-8.4ではPGOビルドの性能を基準としています。(PGOビルドで補正可能なソースコード変更は止めて、コードの差異を減らしています。)

 ということで、支援者配布用にPGOビルドパッケージを制作することにしまして…
ついに（！）

• (一応)現行現役のバージョンで
• (世界で最も長くMySQLの性能を見てきた私の)納得の行く性能を
…

MySQL 8.0.46 ベースに見ていく。

まずは俺の好きな sql/sql_yacc.yy からダイブ。 CHECK TABLE の定義はこのへん。

 9627 check_table_stmt:
 9628           CHECK_SYM table_or_tables table_list opt_mi_check_types
 9629           {
 9630             $$= NEW_PTN PT_check_table_stmt(YYMEM_ROOT, $3,
 9631                                             $4.flags, $4.sql_flags);
 9632           }
 9633         ;
 9634
 9635 opt_mi_check_types:
 9636           %empty { $$.flags = T_MEDIUM; $$.sql_flags= 0; }
 9637         | mi_check_types
 9638         ;
 9639
 9640 mi_check_types:
 9641           mi_check_type
 9642         | mi_check_type mi_check_types
 9643           {
 9644             $$.flags= $1.flags | $2.flags;
 9645             $$.sql_flags= …

TL;DR

• yt-mdl-checker というスクリプトを書いた
• performance_schema.metadata_locks から PENDING になっている EXCLUSIVE なロックを引いて、同じテーブルで既に GRANTED になっているやつを KILL するスクリプト
• クエリ自体は大したことないので、わざわざスクリプト使わなくてもスニペットとして使えるはず
  • https://github.com/yoku0825/ytkit/blob/036be21ff0cc56ec8fadc523e2d2ab4e6965f685/lib/Ytkit/MySQLServer.pm#L1159-L1216
  • MDLが多すぎて p_s.metadata_locks …

TL;DR

• たとえシングルプライマリモードだろうと、GTIDは「そのマシンが使うレンジ」が先に割り当てられて、その中からGTIDを払い出していく
  • レンジの大きさは group_replication_gtid_assignment_block_size デフォルト100万で決められる
• 元プライマリが使っていたGTIDレンジは、割り当てられたレンジが使い切られない限り、再びプライマリに戻った時に再利用する。

yt-sandbox …

• 概要
• 関連用語
• バージョンモデルの変遷
  • Long-Term Support(LTS)リリースシリーズ導入
  • …

バイナリログからデータを吸い出したいケース

MySQL の障害復旧というと、まずバックアップからの復元（PITR）が思い付きます。 しかし実際の運用では、データベース全体を過去の時点へ戻したいとは限りません。

例えば、アプリケーションのバグなどで、レコードごとに異なるタイミングで誤った更新が行われることがあります。このような場合、レコードごとに異なる時点のデータが必要になります。

このような場合に役立つのがバイナリログ（ binlog ）です。 バイナリログ には INSERT、UPDATE、DELETE といった変更履歴が記録されているため、

• どのレコードが
• いつ
• どのように変更されたか

を後から追跡できます。

バイナリログの形式

binlog …