MIXED のロギング形式で実行すると、サーバーは次の条件のときにステートメントベースのロギングから行ベースのロギングに自動的に切り替わります。

以前のリリースでは、混合バイナリロギング形式が使用されていたときに、ステートメントが行ごとにログに記録され、ステートメントを実行したセッションに一時テーブルがある場合、そのセッションで使用されているすべての一時テーブルが削除されるまで、後続のすべてのステートメントは安全でないものとして扱われ、行ベース形式でログに記録されていました。 MySQL 8.0 の時点では、一時テーブルに対する操作は混合バイナリロギング形式で記録されず、セッション内に一時テーブルが存在しても、ステートメントごとに使用されるロギングモードには影響しません。

前述の判断のほかに、テーブル内の情報が更新されるときに使用されるロギング形式が、個々のエンジンによって決定される場合もあります。 個々のエンジンのロギング機能は、次のように定義することができます。

ある特定のストレージエンジンは、いずれかまたは両方のロギング形式をサポートできます。 次の表に、各エンジンによってサポートされる形式を示します。

ステートメントをログに記録するかどうか、および使用されるロギングモードは、ステートメントのタイプ (安全、安全でない、またはバイナリの注入)、バイナリロギング形式 (STATEMENT、ROW、または MIXED)、およびストレージエンジンのロギング機能 (ステートメント対応、行対応、両方、またはいずれか) に従って決定されます。 (バイナリインジェクションとは、ROW 形式を使用してログに記録する必要がある変更のロギングのことをいいます。)

ステートメントがログに記録されるときに警告を出す場合と出さない場合があります。失敗したステートメントはログに記録されませんが、ログにエラーが生成されます。 これを次のデシジョンテーブルに示します。 Type、binlog_format、SLC および RLC のカラムは条件の概要を示し、エラー / 警告およびログイン名のカラムは対応するアクションを表します。 SLC 「「statement-logging 対応」」を表し、RLC は「「行ロギング対応」」を表します。

決定によって警告が生成される場合、標準の MySQL 警告が生成されます (警告は SHOW WARNINGS を使用して確認できます)。 この情報は mysqld エラーログにも書き込まれます。 ログがいっぱいになるのを防ぐために、エラーは各クライアント接続のエラー発生ごとに 1 つだけログに記録されます。 ログメッセージには試行された SQL ステートメントが含められます。

レプリカに警告を表示するように設定された log_error_verbosity がある場合、レプリカはメッセージをエラーログに出力して、ジョブを開始するバイナリログとリレーログの座標、別のリレーログへの切替え時、切断後の再接続時、ステートメントベースのロギングに安全でないステートメントなどのステータスに関する情報を提供します。