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 を表示します。