MySQLアーキテクチャとストレージ層の位置づけ

MySQLサーバーの内部処理フローは、クライアント接続を管理する通信層、クエリの解析とキャッシュを担うサービス層、データの永続化および検索パスを実行するエンジン層、そして物理メディアへ書き込むストレージ層の4階層で構成されています。バージョン5.5以降、システム標準のバックエンド処理はInnoDBに統一されていますが、エンジンごとにインデックスのアルゴリズムやロックの粒度が根本的に異なるため、ワークロードに応じたパフォーマンス特性を把握することが不可欠です。

ストレージエンジンの定義と適用スコープ

ストレージエンジンとは、レコードの物理配置、インデックス構造の構築、およびINSERT/UPDATE/DELETE/SELECTの各処理を実行する技術スタックを指します。この設定はデータベーススキーマ単位ではなく、個別のテーブルに適用されます。別名「テーブルタイプ」とも呼ばれ、同一のデータベース内で業務要件に応じて複数のエンジンを選択・混在させるアーキテクチャが標準的に採用可能です。

サポートエンジンの確認とDDLでの指定方法

稼働中のインスタンスが利用可能なエンジン一覧およびデフォルト状態は、以下のステートメントで確認できます。

SHOW ENGINES;

実行結果の Support カラムが DEFAULT または YES となっているものが利用可能です。旧来から存在するMyISAMに加え、揮発性データを扱うためにMEMORYなどがリストアップされます。

テーブル生成時に特定の処理方式を適用する場合は、DDLの末尾に ENGINE オプションを明示します。

CREATE TABLE inventory_logs (
    log_id INT AUTO_INCREMENT PRIMARY KEY,
    sku_code VARCHAR(32) NOT NULL,
    quantity_change INT DEFAULT 0,
    updated_dt DATETIME DEFAULT NOW()
) ENGINE=MyISAM CHARSET=utf8mb4;

この構文により、対象オブジェクトのデータ操作が指定されたバックエンド実装に委譲されます。

主要ストレージエンジンの仕様比較

InnoDB：高信頼性のトランザクション処理

• トランザクション対応：ACID特性を完全に実装し、障害発生時でもデータの一貫性を保証。
• ロック粒度：行レベルロックを採用。複数セッションによる同時更新時の競合を最小化し、並列スループットを向上。
• 参照整合性：外部キー制約（FOREIGN KEY）をサポートし、親子テーブル間のデータ矛盾をシステムレベルで防止。
• 物理ファイル構成：innodb_file_per_table が標準有効化されており、各テーブルは独立した テーブル名.ibd ファイル（表空間）に定義、実データ、およびインデックスを格納します。
• 論理ストレージ階層：「表空間 → セグメント → エクステント（1MB固定） → ページ（16KB固定） → 行」の構造で管理されます。ディスクI/Oの最小単位はページであり、1つのエクステントは64ページの集合体として割り当てられます。

MyISAM：読み込み最適化の軽量エンジン

• 機能制限：トランザクションおよび外部キー制約は非対応。クラッシュリカバリー機能も限定的。
• ロック方式：テーブルレベルロックのみサポート。同時書き込みには脆弱ですが、単一クエリによる全件走査や一括挿入は高速に処理。
• ファイル分割：構造定義（.sdi）、データ本体（.MYD）、インデックスツリー（.MYI）の3ファイルに物理的に分離されて保管されます。

MEMORY：揮発性インメモリーテーブル

• 保存領域：全データがRAM上に展開されるため、ディスクI/Oが排除され極めて高速。
• インデックス形式：標準ではハッシュインデックスが採用され、等価条件の検索に対してO(1)のパフォーマンスを発揮。
• ファイル構成：実データはメモリ上に存在するため、永続化されるのはテーブル定義情報のみ（.sdi）。サーバー停止やメモリ逼迫時にデータは消失します。

業務シナリオに応じた選定ガイドライン

各エンジンの特性を踏まえた適用領域は以下の通りです。

• InnoDB：決済処理や在庫管理など、複数操作が関連し合い、データの整合性と並列更新性能が必須となるシステム。現代のMySQL運用では大半のケースでこのエンジンが標準選択されます。
• MyISAM：アクセスログの蓄積やマスタデータ参照など、更新頻度が低く高速な読み込みが主目的のワークロード。ただし、現代ではドキュメント型データベースや全文検索エンジンへの移行が一般的です。
• MEMORY：セッション情報保持、集計用一時表、クエリ結果のキャッシュなど、永続性が不要で速度が最優先となる領域。データサイズ制限とクラッシュ耐性の欠如から、専用の分散キャッシュシステム（Redis等）への置き換えが推奨されます。