MySQLには、運用・監視・トラブルシューティングに不可欠な複数のログ種別が存在する。主なものとして、エラーログ、スロークエリログ、トランザクションログ（redo log / undo log）、バイナリログ（binlog）がある。

1. エラーログ（Error Log）

エラーログは常に有効であり、MySQLサーバーの起動・停止時の情報や重大な警告・エラーを記録する。設定項目 log_error でファイルパスが指定される。例：

log_error = ".\DESKTOP-VH518HU.err"

ログ内容には以下のような情報が含まれる：

• サーバー起動時の初期化メッセージ
• InnoDBのバッファプールやリカバリ処理の詳細
• 接続異常やSSL設定の警告
• 非推奨機能の使用に関する通知

このログはシステム障害時の原因特定に極めて重要である。

2. スロークエリログ（Slow Query Log）

実行時間が閾値を超えたSQL文を記録する。デフォルトの閾値は10秒で、以下のパラメータで制御される：

slow_query_log = ON
slow_query_log_file = "DESKTOP-VH518HU-slow.log"
long_query_time = 10

「実行時間」にはロック待ちやネットワーク遅延も含まれるため、単純なクエリでも競合によりスローログに記録される可能性がある。性能チューニングの際に有用。

3. トランザクションログ（InnoDB固有）

InnoDBストレージエンジンは、ACID特性を保証するために二種類のログを管理する。

3.1 redo log（リドゥログ）

物理的な変更内容を記録し、クラッシュ後のデータ復旧に使用される。書き込みフローは以下の通り：

1. トランザクション中の変更 → redo log buffer（ユーザ空間）
2. → OSバッファ（カーネル空間）
3. → ディスク上の ib_logfile*（永続化）

永続化タイミングは innodb_flush_log_at_trx_commit で制御：

• 0：毎秒1回バッファ→ディスク（最大1秒分のデータ損失リスク）
• 1：コミット時に即時fsync（安全性最高、I/O負荷大）← デフォルト
• 2：コミット時にOSバッファへ書き込み、毎秒fsync（電源障害時のみ損失）

redo logは512バイト単位のブロックで構成され、ページ単位の物理変更を記録する。

3.2 undo log（アンドゥログ）

論理的な逆操作を記録し、ロールバックやMVCC（Multi-Version Concurrency Control）を実現する。例えばDELETE操作に対してはINSERTの逆操作を記録。

各テーブル行には内部的に以下の隠しカラムが存在：

• trx_id：最後に更新したトランザクションID
• roll_pointer：undoログへのポインタ（バージョンチェーンを形成）

undo log自体も変更されるため、その変更内容はredo logにも記録される。

4. バイナリログ（Binary Log, binlog）

データベースの変更操作（INSERT/UPDATE/DELETE）を記録し、主に以下に使用：

• ポイントインタイムリカバリ
• MySQLレプリケーション（マスター→スレーブ同期）

有効化には log_bin = ON を設定。ログ形式は binlog_format で選択可能：

• STATEMENT：SQL文そのものを記録。容量小だが非決定的関数（例: NOW()）で不整合リスク
• ROW：変更された各行の前後イメージを記録。正確だが容量大
• MIXED：安全な場合はSTATEMENT、危険な場合はROWに自動切り替え

ディスクへの同期頻度は sync_binlog で制御。値が1の場合、各コミットで即時同期（安全性高）。

5. クラッシュからの復旧プロセス

MySQLが異常終了した場合、以下の手順で復旧が行われる：

1. チェックポイント（checkpoint）以降のLSN（Log Sequence Number）を持つredoログをスキャン
2. ダブルライトバッファ（doublewrite buffer）を用いてページ破損を検出し、必要なら修復
3. コミット済みトランザクションのredoログを適用し、データページを最新状態に更新
4. 未コミットトランザクションをundoログに基づきロールバック

このプロセスにより、ディスク上のデータが一貫性のある状態に保たれる。