MariaDB serverを10.11から11.8にアップグレード
MariaDB serverをアップグレードしたときの覚書。
Gemini 3 Pro Previewと対話。
環境： FreeBSD 14.3-RELEASE-p7
１． MariaDB 10系と11系の違い
主にWordPressを複数運用するウェブサーバー向けにGemini先生にまとめてもらった。
- オプティマイザ（頭脳）の刷新:
11系ではSQLの実行計画を決めるロジックが「コストベース」に完全刷新されており、複雑な商品検索（WooCommerce等）が高速化する可能性がある反面、統計情報が古いと単純なクエリでインデックスを使わなくなるなどの「判断ミス」による急激な速度低下リスクが高まっている。 - 書き込み性能の向上:
11系は内部的なログ処理（Redo Log）が改善されており、複数のWordPressサイトから同時にアクセスや記事更新が発生するような高負荷時のディスクI/O効率が良く、書き込み待ちが起きにくくなっている。 - サポート期間と安定性:
10.11は「旧設計の完成形」として2028年2月までサポートされる最も枯れた安定版（LTS）ですが、11系は新設計のため挙動が異なり、現在のLTSは11.4となっている（11.8は将来のバージョン）。 - 古いプラグインの互換性リスク:
11系では古いMySQL時代から残っていた非推奨機能や曖昧な設定が削除されているため、長年更新されていない古いWordPressプラグインがエラーを起こして動作しなくなる可能性が10系より高い。 - JSON処理の高速化:
最近のWordPressプラグインやブロックエディタが多用する「JSON形式」のデータ処理能力が11系で強化されており、関連する処理が軽くなる傾向がある。 - 統計情報管理の厳格化:
11系の新オプティマイザはデータの「統計情報（件数や分布）」に非常に敏感なため、アップグレード後や記事大量追加後に ANALYZE TABLE を実行して情報を最新に保たないと、10系よりもパフォーマンスが劣化しやすくなる。 - メンテナンス性の向上:
11系はテーブル構造の変更（Instant DDL）機能が強化されており、巨大なテーブルへのカラム追加などを、サービスを停止させずに瞬時に行える範囲が広がっている。 - リソース効率:
11系の方がメモリ管理や一時テーブルの扱いが効率化されており、限られたメモリ内で多数のWordPressを動かす際のオーバーヘッドがわずかに減少する傾向がある。
２． アップグレードするシェルスクリプト
ダウンタイムなしでアップグレードすることはできないので、Gemini先生に一連の流れをシェルスクリプトにしてもらった。
参考： MariaDB serverを10.11から11.8にアップグレード
実行する前に開発環境で動作テストする。
（スナップショットを取っておく）
実行。
# chmod +x upgrade_mariadb.sh
# ./upgrade_mariadb.sh
大量のデータを一括処理した後は手動で統計情報を更新する。
# mariadb-check -u root -p --analyze --all-databases
特定のデータベース「medical」に行う場合のコマンド。
# mariadb-check -u root -p --analyze --databases medical
MariaDB（InnoDBエンジン）は、「永続的統計情報 (Persistent Statistics)」 という機能がデフォルトで有効になっている。
これにより、通常の運用中に統計情報を更新する必要はない。