含まれると予想できます。これはそうなりません。スレーブコピーから選択すると、マスターとまったく同じ結果になります。異なり、レプリケーションに安全ではありません。ステートメントに影響されず、ステートメントベースロギングが使用される場合は非決定的であるためです。行ベースロギングを使用する場合は、これは問題ではありません。エイリアスになります。機能するには、これをマスターとスレーブで行う必要があります。マスターとスレーブの両方で使用されるかぎり安全に無視できます。モードで警告を生成します。#47995)セクション17.4.1.30「レプリケーションとタイムゾーン」も参照してください。次の制限は、ステートメントベースレプリケーションにのみ適用され、行ベースレプリケーションには適用されません。関数は、スレーブがマスター上の並列コンテキストを知ることなく複製されます。したがって、スレーブ上の内容が違ってしまうため、これらの関数を使用してマスターテーブルに挿入しないでください。ステートメントを発行しないでください。モードで警告を生成します。#47995)ステートメントベースレプリケーションが有効のときに前述の制限に対する回避策として、問題のある関数結果をユーザー変数に保存して、後続のステートメントでその変数を参照する方法を使用できます。関数を参照するため問題があります。VALUES(UUID());この問題を回避するには、代わりにこれを実行してください。VALUES(@my_uuid);このステートメントの連続は複製されます。同じ概念が複数行挿入に適用されますが、使用するのが面倒です。行挿入の場合、このようにできます。VALUES(@my_uuid1),(@my_uuid2);ただし、行数が多いか不明の場合、この回避策は困難であるか実用的でありません。次のステートメントを個々のユーザー変数が各行に関連付けられているものに変換することはできません。回だけ呼び出されるかぎり、正しく複製されます。(関数実行タイムスタンプと乱数シードをマスターとスレーブで同じ暗黙的入力と見なすことができます。関数がステートメントベースレプリケーションを使用して複製されるときは、信頼性がありません。ステートメントでこれを使用することです。いう名前のテーブルに結果を格納する場合は、普通は次のように実行するかもしれません。使用してから変数をテーブルに格納することをお勧めします。VALUES(@found_rows);このようにすることで、ユーザー変数はコンテキストの一部として複製され、スレーブ上で正しく適用されます。モードで警告を生成します。値は正しく複製されませんでした。