はじめに
MariaDB 13.0 が 2026年3月23日にプレビュー版としてリリースされ、5月26日にはバージョン 13.1 がリリースされたことをご存知でしょうか。
MariaDB 13.0は、Rolling Release（Innovation Release）として提供され、約3か月ごとに新機能を取り込んだリリースが公開されます。そのため、最新機能をいち早く利用することができます。
ただし、本番環境などで使用する際は、GA版である MariaDB 12.3.2 を使用してください。
本ブログ記事では、MariaDB 13.0.0と13.1.0 で追加された機能のうち、MariaDB ユーザー目線で便利そうな機能をいくつかピックアップしてご紹介します。
詳細な追加機能一覧については公式ドキュメントを参照してください。
MariaDB 13.0.0 追加機能のピックアップ
INFORMATION_SCHEMAの強化
Show Deprecated Variables That are set in the Configuration File
ポイント
INFORMATION_SCHEMA.SYSTEM_VARIABLESに非推奨情報が追加された- これにより、SQLだけで「将来的に見直しが必要なパラメータ変数」が確認でき、アップグレード前の棚卸しや運用ツールによる自動チェックが行いやすくなる
従来はバージョンアップ前の確認時に、設定ファイルのパラメータ変数に対してドキュメントを照らし合わせて非推奨になっていないかをチェックする必要があり、かなり煩雑な作業でした。
以下のクエリでは非推奨となった変数を表示するとともに、DEPRECATED_REPLACEMENT カラムで置き換え後の変数も表示しています。
地味ですが便利な機能です。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
MariaDB > SELECT variable_name,DEPRECATED_REPLACEMENT -> FROM information_schema.system_variables -> WHERE IS_DEPRECATED='YES'; +-----------------------------------+----------------------------------+ | variable_name | DEPRECATED_REPLACEMENT | +-----------------------------------+----------------------------------+ ： | BINLOG_OPTIMIZE_THREAD_SCHEDULING | NULL | | TX_READ_ONLY | transaction_read_only | ： +-----------------------------------+----------------------------------+ |
DEPRECATED_REPLACEMENT カラムがNULL の場合、パラメータ置換は行われません。
そのため、NULL の場合、機能自体がなくなるのか、デフォルト機能として組み込まれるのかをドキュメントで確認する必要があります。
また、deprecated＝将来削除される予定のパラメータなので、今すぐにパラメータが使えなくなるというわけではないため、本機能は今後対応が必要となるものを洗い出すという使い方になります。
CREATE OR REPLACE TABLE ステートメントがアトミックな処理に
ポイント
CREATE OR REPLACE TABLEが、途中で失敗してもテーブルを失わない安全なDDLになった- 「既存テーブルを消してから新しいテーブルを作る」という危険な処理を「新しいテーブルが完成するまで古いテーブルを保持する」方式へ変更
CREATE OR REPLACE TABLE ステートメントはテーブルが既に存在する場合、既存のテーブルを削除し、新しく定義されたテーブルに置き換えるというものです。
従来の処理は内部的に DROP TABLE –> CREATE TABLE というDDLチェーン処理されていました。
そのため、 CREATE が失敗したり、 DROP 直後にサーバクラッシュするとテーブルが消える、DDLの途中状態となるリスクがありました。
MariaDB 13.0では内部的な処理がAtomic DDLに対応し、処理途中で失敗しても既存テーブルを失わない仕組みに改善されました。 そのため、もし CREATE に失敗しても元のテーブルが復元されるため、クラッシュ耐性向上しました。
夜間バッチや集計テーブルなどでCREATE OR REPLACE TABLEを利用する処理では、途中で失敗するとテーブル自体が消失する恐れがありましたが、処理がアトミックになったことで運用事故が低減されより安全になったと言えます。
MariaDB 13.1.0 追加機能のピックアップ
PARTITION BY RANGE用の新しいパーティションの自動追加
ポイント
CREATE TABLE文のPARTITION BY RANGEのINTERVAL句を指定すると、INSERT時に対象パーティションが存在しない場合は設定した時間隔ごとにパーティションが自動作成されるようになった- パーティションが存在しない範囲のデータ挿入でも、パーティションが自動生成され
INSERTエラーが発生しづらくなる
これは「日時パーティションを運用するために、DBAが定期的にパーティションを追加し続けなければならない」という運用上の問題に使えるレンジパーティショニングの拡張機能となります。
例えば、以下のようにテーブルを日単位でパーティション化しているケースで考えます。
|
1 2 3 4 5 6 7 8 |
PARTITION BY RANGE (log_date) ( PARTITION `p20260713` VALUES LESS THAN ('2026-07-14') ENGINE = InnoDB, PARTITION `p20260714` VALUES LESS THAN ('2026-07-15') ENGINE = InnoDB, PARTITION `p20260715` VALUES LESS THAN ('2026-07-16') ENGINE = InnoDB, ); |
この時、log_date列の値が 2026-07-16以降になるとパーティションが存在せず、INSERTは失敗します。
そのため、このようなケースではパーティション追加を夜間メンテナンスなどで対応しているユーザーも多いかと思います。
今回の機能追加は、INSERT時に対象パーティションが存在しない場合、自動でパーティションを生成するというものです。
INTERVAL 句で指定できるパーティション単位は SECOND、MINUTE、HOUR、DAY、MONTH、YEARです。
以下の例では DAYを指定し、1日単位にパーティションを自動生成します。
|
1 2 3 4 5 6 7 |
CREATE TABLE test.t1 (log_date date) PARTITION BY RANGE COLUMNS (log_date) INTERVAL 1 DAY ( PARTITION p20260701 VALUES LESS THAN ('2026-07-02') ); |
試しにパーティションが存在しない範囲のデータを追加します。
本来、INTERVAL句を指定していない場合はこの時点でTable has no partition for value from column_listエラーでINSERTが失敗しますが、問題なく成功します。
|
1 2 3 |
MariaDB > insert into test.t1 values ('2026-07-10'); Query OK, 1 row affected (0.543 sec) |
SHOW CREATE TABLEで確認すると、パーティションp1～p15が日単位で自動作成されたことがわかります。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
CREATE TABLE `t1` ( `c` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci PARTITION BY RANGE COLUMNS(`c`) INTERVAL 1 DAY (PARTITION `p20260701` VALUES LESS THAN ('2026-07-02') ENGINE = InnoDB, PARTITION `p1` VALUES LESS THAN ('2026-07-03') ENGINE = InnoDB, PARTITION `p2` VALUES LESS THAN ('2026-07-04') ENGINE = InnoDB, : PARTITION `p9` VALUES LESS THAN ('2026-07-11') ENGINE = InnoDB, : PARTITION `p15` VALUES LESS THAN ('2026-07-17') ENGINE = InnoDB) |
本機能についてはまだ公式ドキュメントには記載がないため、挙動から察するにINSERTした時点の日時までのパーティションが自動作成されるようです。
先ほどの例ですと、データ挿入は2026-07-17に実行したため 2026-07-17 までの日単位パーティションが自動で生成されています。
本機能は、パーティション追加忘れによる障害を防止できる機能であり、ログや履歴テーブルをパーティション運用しているユーザーにとっては、運用負荷を減らせる改善です。
注意点
まだ公式ドキュメントには記載がないため、挙動から察するに現時点は以下の注意点があります。
PARTITION BY RANGE COLUMNSで指定した列型が保持する情報より細かい粒度ではパーティション作成できません- たとえば、DATE型なら時分秒を持たないため、
HOUR/MINUTE/SECONDは指定したパーティション単位に指定できません。 - パーティション名は
p1から連番 - 自動生成されるパーティション数が多くパーティションニングの制限 を超える場合、
Too many partitions (including subpartitions) were definedエラーが発生し、INSERTが失敗します。 - 各テーブルには最大8192個までです。単位が
YEAR/MONTH/DAYなら特に問題にならないですが、HOUR/MINUTE/SECONDを指定するとあっという間に制限をこえるので注意が必要です。
特にパーティション名は分かりやすいものを命名したいニーズはあると思うので、今後改良されるとより使い勝手が良いと感じました。
InnoDBテーブルごとのAHI有効化
ポイント
- Adaptive Hash Index(以降、AHI) が InnoDBテーブルごとに有効化/無効化できるようになった
- テーブルオプションの
ADAPTIVE_HASH_INDEXの設定で制御する
まず、AHIには次の特徴があります。
- 読み取り中心のテーブルでは、B-treeを何段もたどる代わりにハッシュ検索できるため、高速化が期待できる
- 一方で、更新が多いテーブルでは、AHIのエントリを更新・削除するコストやラッチ競合が発生し、かえって性能が悪化することがある
そのため、AHIをONにすると「読み込みが多いテーブルは高速化される」が「更新が非常に多いテーブルは性能が落ちる」ということが起こり得ました。
AHIを利用していたが全体最適化を考慮して、AHIを無効化したというユーザーも多かったのではないでしょうか？
MariaDB 13.1では、ワークロードに応じてテーブル単位でAHIを使い分けられるようになりサーバー全体ではなく、テーブルごとに最適な動作を選べるようになりました。
以下のテーブルオプション ADAPTIVE_HASH_INDEXで制御ができます。
|
1 2 |
MariaDB > ALTER TABLE test.t1 adaptive_hash_index='YES'; |
DEFAULT: テーブル固有の設定を持たず、グローバル変数 innodb_adaptive_hash_index の設定に従います。（デフォルト値）YES:当該テーブルに対して、AHI を使用する。- ただし、AHI が実際に構築されるのは、サーバーレベルでも AHI が有効になっている場合のみ
NO：当該テーブルに対して AHI を使用しない。
設定値YESの「ただし、AHI が実際に構築されるのは、サーバーレベルでも AHI が有効になっている場合のみ」という部分で「結局、サーバーレベルでAHIが有効化されたら全テーブルで有効になるのでは？」と疑問を持たれた方、安心してください。
Mariadb 13.1から innodb_adaptive_hash_indexを IF_SPECIFIEDを指定すれば、ADAPTIVE_HASH_INDEX=YES が設定されたテーブルまたはインデックスに対してのみ AHI が有効になるように改善されています。
(https://mariadb.com/docs/server/server-usage/storage-engines/innodb/innodb-system-variables#innodb_adaptive_hash_index)
テーブルごとにAHIを有効化すると、以下のように adaptive_hash_index=YES が確認できます。
|
1 2 3 4 5 6 7 8 9 |
MariaDB > show create table test.t1; +-------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+--------------------------------------------------------------------------------------------------------------------------------------------------+ | t1 | CREATE TABLE `t1` ( `id` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci `adaptive_hash_index`='YES' | +-------+--------------------------------------------------------------------------------------------------------------------------------------------------+ |
ここまでの話を整理すると、テーブルごとにAHIを有効化したい場合は以下の設定が必要です。
innodb_adaptive_hash_indexをIF_SPECIFIEDに設定- AHIを有効化したいテーブルの
ADAPTIVE_HASH_INDEXをYESに設定
例えば、ECサイトの商品マスタのような読み取り中心テーブルではYES、注文履歴のように更新が多いテーブルではNOを検討できます。
これまでAHIを利用していたがやむなく無効化していたユーザーにとっては使える機能だと感じる方も多いのではないでしょうか。
まとめ
MariaDB 13.0.0、13.1.0では運用改善や調査機能の拡充がメインのように感じましたが、性能向上のための機能改善も一部行われています。
特にAHIのテーブルごとの有効化機能など「特定の状況でしか有効ではない機能をテーブル単位で制御でする機能」は続々と増えることに期待しております。例えば QUERY_CACHE のテーブル単位制御なども今後機能追加される可能性もあります。)
このような機能が増えていくことで、全体最適化を優先して無効化していた機能がパフォーマンスチューニングとして導入しやすくなります。
ぜひ、MariaDB ユーザーの皆様も新機能を検証してみてください！
