MariaDB 12系の初LTSである、12.3がリリースされました。
https://mariadb.com/docs/release-notes/community-server/12.3/mariadb-12.3-changes-and-improvements
12系を見て、ちょっときになった点を挙げておきます。
（CTEのUPDATE/DELETE対応）
これまではINSERTだけだったので、ちょっとうれしい。
INSERTと違って、UPDATE/DELETEは最後に書くみたいです。
（MySQLのcaching_sha2_passwordとの互換）
これも嬉しいですね。これまでも通っていたのですが、完全な互換ではなかったようです。
（Optimizer Hints の導入）
あんまり使うことはないのですが、集計クエリーでちょっとオプティマイザを変えたいなと思うときは便利です。
（外部キーの制約名の一意性変更）
外部キーのConstraintNameは、データベース内で一意である必要があったのですが、
今後はテーブル内一意でよいそうです。
データベース一意だと、REPLACEとかで邪魔になるからだそうです。
（InnoDBにおけるWALログとバイナリログの統合）
これはすごいですね。内部XAトランザクションが省略されるので、かなりパフォーマンスアップになると思います。
色々制約はあるようですが、以下が詳しく解説してくれています。
https://blog.s-style.co.jp/2026/04/15832
（REPEATABLE READの挙動変更）
私は、普段は「READ-COMMITTED」で、「for update」などのロックを使ってしまうので、
あんまり関係ないですが、「REPEATABLE-READ」を使っている人は要注意です。
というわけで、ちょっと検証してみました。
1．transaction_isolationが「REPEATABLE-READ」で、innodb_snapshot_isolationが「0」
従来の「REPEATABLE-READ」の挙動です。
| (SESSION A) | (SESSION B) |
| > begin; | |
| > begin; | |
| > select * from t1 where id = 1; +—-+——+ | id | name | +—-+——+ | 1 | taro | +—-+——+ | |
| > select * from t1 where id = 1; +—-+——+ | id | name | +—-+——+ | 1 | taro | +—-+——+ | |
| > update t1 set name = ‘jiro’ where id = 1; Query OK, 1 row affected (0.001 sec) | |
| > update t1 set name = ‘saburo’ where id = 1; Query OK, 1 row affected (4.352 sec) | |
| > commit; | |
| > commit; | |
| > select * from t1 where id = 1; +—-+——–+ | id | name | +—-+——–+ | 1 | saburo | +—-+——–+ ★「jiro」でUPDATEしたはずなのに、消えた！ |
2．transaction_isolationが「REPEATABLE-READ」で、innodb_snapshot_isolationが「1」
12.3のデフォルトの挙動です。
| (SESSION A) | (SESSION B) |
| > begin; | |
| > begin; | |
| > select * from t1 where id = 1; +—-+——+ | id | name | +—-+——+ | 1 | taro | +—-+——+ | |
| > select * from t1 where id = 1; +—-+——+ | id | name | +—-+——+ | 1 | taro | +—-+——+ | |
| > update t1 set name = ‘jiro’ where id = 1; Query OK, 1 row affected (0.001 sec) | |
| > update t1 set name = ‘saburo’ where id = 1; ★SESSION AのCOMMITまで待ちになる | |
| > commit; | |
| ERROR 1020 (HY000): Record has changed since last read in table ‘t1’; try restarting transaction ★SESSION AのCOMMIT後、上記エラーとなる |
というように、挙動が変わります。
これは個人的には正しい挙動かと思います。
とはいえ、これを理解して、ロックを回避するというのを開発側に伝えるのもちょっと難しい気もします。
ロックがない分散DBなんかも、こんな形でエラーを起こすことはあると思うので、どっかで役に立つかもしれません。
ちなみに、私の作っているmagntadeskでは、0.9.3で、MariaDB12.3に対応しています。
https://github.com/shigenobu/magentadesk/releases
以上