長時間の操作中に接続が失われた場合はどうなりますか?
たとえば、完了するまでに数分かかる select ステートメントがあり、その実行中に接続が失われます。実行を継続しますか、それとも停止しますか?
delete ステートメントの場合: クライアントが切断されたときに最後まで実行されるか、中断されますか? データはどうなりますか: コミットまたはロールバックされるのはいつですか?
ddl 操作の場合: 実行時間の長いalter table tbl_name move操作があります。クライアントが接続を失った場合、操作はどうなりますか? 実行を続行しますか、それとも中断しますか?
クライアント アプリケーションのクラッシュやネットワーク接続のドロップに似たものについて話していると想定しています。ステートメントが実行されています。
一般に、ステートメントはサーバー上で完了するまで実行されます (a の「完了」はSELECT、クライアントが要求した行の最初のセットを返すことができるポイントであり、ステートメント全体を実行する必要がある場合とそうでない場合があります)。サーバーは、結果の準備ができているという事実をクライアントに伝えようとします。応答が返ってこない場合 (タイムアウトになるまでに数分かかる場合があります。ACKクライアント プロセスが停止していることを認識し、コミットされていないトランザクションをロールバックするプロセスを開始します (これにより、トランザクションによって保持されているすべてのロックが解放されます)。トランザクションの一部としてデータベースに変更を加えた場合 (つまり、挿入、更新、および/または削除を行った場合)、最初に変更を生成するのにかかったのと同じくらい、変更をロールバックするのに時間がかかることがあります。
selectやのような単純な DML ステートメントの場合delete、トランザクションはロールバックまたはコミットされます。
これは「いつ」発生しますか？ それは実際には問題ではありません。他のクライアントには、コミットされたトランザクションの結果しか表示されないため、タイミングは関係ありません。
DDL ステートメントの場合、公式ドキュメントによると、「データベースが DDL ステートメントを実行する直前に暗黙の COMMIT が発生し、その直後に COMMIT または ROLLBACK が発生します」。
トランザクション内で、いくつかの DML ステートメントを実行してから DDL ステートメントを実行した場合、DML ステートメントはコミットできますが、DDL ステートメントはロールバックされます。それらはすべて同じトランザクション内にあるにもかかわらずです。
ただし、あなたが示した単純な例については、すべてかゼロかです。...そして一般的に、コミットされたトランザクションの確認を受け取る前に接続を失った場合、それが機能したかどうかはわかりません。確認する必要があります。
[編集： 「確認する必要がある」ことについて少し詳しく説明します...データベースに「コミット」を（明示的または暗黙的に）送信したかどうかを確認する必要があり、データベースが実行されたかどうかを知る前に接続が失われますコミット。
コミットを発行する前に接続が失われた場合は、ロールバックされることが保証されます (上記の DDL に関する注意事項があります)]
すべてのデータベース操作は、プロパティに従って機能しACIDます。
Atomicity
データに対するすべての変更は、1 回の操作であるかのように実行されます。つまり、すべての変更が実行されるか、またはどれも実行されません。
つまり、原子性に従って、変更がロールバックされます。