START TRANSACTION | BEGIN [WORK] COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE] SET AUTOCOMMIT = {0 | 1}
START TRANSACTION
と BEGIN
ステートメントは新しいトランザクションを始めます。COMMIT
は、その変更を恒久的な物にし、現在のトランザクションを行います。ROLLBACK
はその変更をキャンセルし、現在のトランザクションをロールバックします。SET AUTOCOMMIT
ステートメントは現在の接続にデフォルト自動コミット モードを無効に、そして有効にします。
任意の WORK
キーワードは、CHAIN
と RELEASE
条項のように COMMIT
と ROLLBACK
に対してサポートされています。CHAIN
と RELEASE
はトランザクション完了に対する追加コントロールに利用されます。completion_type
システム変数の値はデフォルトの完了動作を決定します。詳しくは 項 「システム変数」 を参照してください。
AND CHAIN
条項は、現在のトランザクションが終わったらすぐに新しいトランザクションが始まるよう働きかけ、その新しいトランザクションは終わったばかりのトランザクションと同じ分離レベルを持ちます。RELEASE
条項は、現在のトランザクションを終了した後、サーバが現在のクライアント接続を切るよう働きかけます。NO
キーワードを含む事は、もし completion_type
システム変数がデフォルトで変更やリリース完了を引き起こすよう設定されれば有効となる、CHAIN
や RELEASE
完了を食い止めます。
デフォルトにより、MySQL は自動コミットモードが有効な状態で起動します。これは、テーブルを更新(変更)するステートメントを実行したとたん、MySQL がディスク上に更新を格納する、という意味です。
もしトランザクション セーフ ストレージ エンジン(InnoDB
や NDB Cluster
のような物)を利用していたら、次のステートメントを利用して自動コミットモードを無効にする事ができます。
SET AUTOCOMMIT=0;
AUTOCOMMIT
変数をゼロに設定する事で自動コミット モードを無効にした後、ディスクに変更を格納する為には COMMIT
を、またはもしそのトランザクションの最初から行ってきた変更を無視したければ ROLLBACK
を利用しなければいけません。
一連のステートメントに対して自動コミット モードを無効にする為には、START TRANSACTION
ステートメントを利用してください。
START TRANSACTION; SELECT @A:=SUM(salary) FROM table1 WHERE type=1; UPDATE table2 SET summary=@A WHERE type=1; COMMIT;
START TRANSACTION
を利用すると、自動コミットは COMMIT
や ROLLBACK
を利用してトランザクションを終了するまで無効のままです。そして自動コミット モードはその前の状態に戻ります。
BEGIN
と BEGIN WORK
は、トランザクションを始める START TRANSACTION
のエイリアスとしてサポートされています。START TRANSACTION
はスタンダード SQL 構文で、アドホック トランザクションを始める方法として推奨されています。
重要:MySQL クライアント アプリケーションを書く為に利用されている多くの API (JDBC のような)は、トランザクションを始める為に、クライアントから
START TRANSACTION
ステートメントを送る代わりに利用する事ができる(場合によっては利用しなければならない)独自の方法を提供します。更なる情報については、章 23. APIとライブラリー か、ご利用の API の説明書を参照してください。
BEGIN
ステートメントは、BEGIN ... END
複合ステートメントを開始する BEGIN
キーワードの利用とは異なります。後者はトランザクションを開始しません。詳しくは 項 「BEGIN ... END
複合ステートメント構文」 を参照してください。
このようにトランザクションを開始する事もできます。
START TRANSACTION WITH CONSISTENT SNAPSHOT;
WITH CONSISTENT SNAPSHOT
条項は、一貫性のある読み取りが可能であるストレージ エンジンに対して、それを開始します。現在は、これは InnoDB
にだけ適応しています。その効果は、InnoDB
テーブルから SELECT
が後に続く START TRANSACTION
を発行することと同じです。詳しくは 項4. 「一貫非ロック読み取り」 を参照してください。
WITH CONSISTENT SNAPSHOT
条項は現在のトランザクションの分離レベルを変更しないので、現在の分離レベルが一貫性のある読み取りを許容する物である場合のみ(REPEATABLE READ
か SERIALIZABLE
)、一貫性のあるスナップショットを提供します。
トランザクションを開始すると、未解決のトランザクションを引き起こします。詳細については、項 「暗黙のコミットを引き起こすステートメント」 をご参照ください。
トランザクションを開始すると、LOCK TABLES
を利用して行ったテーブル ロックを、まるで UNLOCK TABLES
を実行したかのように解除してしまいます。トランザクションを開始しても、FLUSH TABLES WITH READ LOCK
を利用して行われたグローバル リード ロックの解除はしません。
一番良い結果を得る為には、単一トランザクショナル ストレージ エンジンによって管理されたテーブルだけを利用してトランザクションを行うべきです。そうでなければ、次のような問題が起きます。
もし複数のトランザクション セーフ ストレージ エンジンのテーブルを利用していて(InnoDB
や Falcon
のような)、またトランザクションの分離レベルが SERIALIZABLE
でないならば、1つのトランザクションが行われた時に同じテーブルを利用する別の実行中のトランザクションが、最初のトランザクションによって行われた変更だけを見るという事が可能です。これは、トランザクションのアトミック性が、混合エンジンに保障されておらず、矛盾した結果になり得るという事です。(もし混合エンジン
トランザクションが頻繁でなければ、必要に応じて分離レベルを SERIALIZABLE
に設定する為に、1つのトランザクション単位で SET TRANSACTION ISOLATION LEVEL
を利用する事ができます。)
もし非トランザクション セーフ テーブルをトランザクション内で利用すれば、自動コミットの状態に関わらず、それらのテーブルへの変更は一度に格納されます。
もし非トランザクション テーブルをトランザクション内で更新した後に ROLLBACK
ステートメントを発行すると、ER_WARNING_NOT_COMPLETE_ROLLBACK
警告が発生します。トランザクション セーフ テーブルへの変更はロールバックされますが、非トランザクション セーフ テーブルへの変更はされません。
各トランザクションは COMMIT
によって、1つの塊でバイナリ ログの中に格納されています。ロールバックされたトランザクションはログされません。(例外:非トランザクション テーブルへの変更はロールバックされません。もしロールバックされたトランザクションが、非トランザクション テーブルへの変更を含んでいたら、それらのテーブルへの変更が複製される事を保障する為に、最後にそのトランザクション全体が
ROLLBACK
ステートメントでログされます。)詳しくは 項 「バイナリ ログ」 を参照してください。
SET TRANSACTION ISOLATION LEVEL
を利用してトランザクションの分離レベルを変更する事ができます。詳しくは 項 「SET TRANSACTION
構文」 を参照してください。
ロールバックは、ユーザーが明示的に求めなくても行われる、ゆっくりとした操作になり得ます。 (例えば、エラーが発生した時。)この為、SHOW PROCESSLIST
は、明示的、暗黙的な(ROLLBACK
SQL ステートメント)ロールバックの最中の接続に対する State
カラム内の Rolling back
を表示します。