- 論理アーキテクチャのMySQLサービス
- ACIDトランザクション
- トランザクションログ
- トランザクション分離レベル
- デッドロック
- MVCC
- MySQLのトランザクション
まず、論理アーキテクチャのMySQLサービス
MySQLのサービス組織の論理を理解するためにSQLトランザクションを見ていることは前提条件でなければならない前に、それはなぜトランザクションメカニズムを教えてくれます。そして、どのように取引の仕事を理解することによって、それは何の問題も、これらの問題の背後にある根本的な原因を解決することはできませんすべての問題を解決することができますか？どちらも、論理アーキテクチャサービスからのトリガが必要です。
1.1MySQLサービスロジックチャート：
出典：https://blog.csdn.net/fuzhongmin05/article/details/70904190、MySQLのパフォーマンスの最適化についても、このブログを参照することができます。
MySQLの一般的に3つの論理アーキテクチャに分け、（一般にクライアントとも呼ばれる）、トップレベルのサービスは、MySQLに固有ではない、ほとんどのベースのツールまたはサービスネットワーククライアント/サーバは、同様のアーキテクチャを有します。このような接続処理、認可および認証、セキュリティなど。
二層アーキテクチャは、クエリの解析、分析、最適化、キャッシングなど、MySQLのサービス機能の中核であり、すべての組み込み関数（例えば、日付、時間、数学と暗号化機能）、すべてのクロスストレージエンジンの機能は、この層で実現されています：ストアドプロシージャ、トリガ、およびその他のビュー。
MySQLのデータ記憶及び検索のためにストレージエンジンの最低レベル。そして、Linuxファイルシステムと類似の下で、各ストレージエンジンは、その長所と短所があります。ストレージエンジンAPIと通信するための中間層を介してサービス、APIインターフェースは、これらの違いは、上層に透明なプロセスクエリように、異なるストレージエンジンとの間の差異をシールド。ストレージエンジンAPIは、「トランザクションを開始する」または「行抽出プライマリ・キー」及び他の動作を実行するためのような機能の基礎となる多数を含んでいます。しかし、ない解決ストレージエンジンのSQLに（InnoDBは除く、これは、MySQLサーバ自体がこの機能を実装していないとして、外部キーが定義されて解析し）、それは別のストレージエンジン間で相互に通信し、単にそれぞれの上位サーバを要求しません。 。
1.2同時実行制御：
各サーバ側によって新しい要求が、接続/ツールをスレッディングすると、クライアントの要求を受信するための責任があるクライアントを開始してから、新しいメモリスペースをオープンし、サーバーのメモリに新しいスレッドを作成し、ときに、各ユーザーが接続するサーバーへクライアントの要求に応答するためのプロセスのアドレス空間のプール内の新しいスレッドを生成します際に、ユーザーが開始したクエリは、メモリ空間のスレッドを実行している、そこにもキャッシュの結果であり、サーバに返さ。スレッドの再利用と破壊が接続/スレッド処理マネージャによって達成されます。
単に、ユーザーが開始要求を入れ、接続/スレッドプロセッサは、メモリ空間を開き、クエリを開始するためのメカニズムを提供します。
サービス層とストレージエンジン層：複数のユーザが開始要求がある場合、可能な同時2つのレベルでのMySQL同時制御が存在しなければなりません。一例として、メールボックスのUnixシステムでは、mbox形式は、メールボックス内のすべてのメッセージが一緒に最後までそれぞれのもう一方の端を交差しています。電子メールメッセージと非常に友好的、分析、およびメールの配信を読み取るためのこの形式は、ファイルの末尾に新しいメッセージの内容をすることができアペンド限り、非常に簡単でもあります。
同時に2つのプロセスが同じメールボックスにメールを配信場合でも、右の二つは、エラーの原因となった同時データであるメールボックスファイルの末尾に貼り付けられ横切ることになります。グッドメール配信システムは、ロック（ロック）することで、データの破損を防ぐように設計されます。メールの配信、およびメールへの顧客が別の顧客によってロックされている場合はロックを配信するために解放されるまで、それは待たなければなりません。
これは、プログラムが実際のアプリケーション環境が、うまく動作しますが、サポートの並行処理を保持していないロックされます。いずれかの時間なので、一つだけのプロセスは、メールボックスシステムの大規模な数の問題であり、データメールボックスを、変更することができます。
1.3ロック機構：
1.3.1読み書きロック
同時に複数のユーザーが同じ電子メールの読み出し処理は問題ではありませんが、存在する場合、メールボックスユーザーは、ユーザーの別の実例は決まっていない、結果がどうなるかメッセージ番号25を、削除、読んでいるとき。読むの顧客がエラーを撤回することがあり、それは、メールボックスのデータの不整合に読み取ることができます。メールボックスデータベース内のテーブルとして見た場合、電子メールは、列として、同様の問題は、データベースに存在します。この問題を解決するには、ロックの2種類からなるシステムをロックすることにより、問題を解決するために、同時読み取りまたは書き込みに対処する上で、同時実行制御にあります。ロックのこれらの2つのタイプは、通常、読み取りおよび書き込みロックとして知られ、共有ロックと排他ロックと呼ばれています。
読み込みロック：読み取りロックが共有されている、またはお互いをブロックしないこと。複数のユーザーが干渉することなく、同時に同じリソースを読みますが、書き込みをブロックしますロックを読み取ります。
書き込みロック：書き込みロックは、どの書き込みロックは、他の書き込みをブロックし、読むことを意味排他的です。
1.3.2ロックの粒度：
ロックの粒度は、理想的にはすべてのリソースをロックし、変更するデータの一部をロックしてみてくださいではなく、読み取りと書き込みのロックデータの範囲を指します。例えば、与えられたリソース上で、データのより少ない量がロック、いつでも良好ロックテーブルよりもために行をロックし、並行システムの度合いが高い、すなわち、長い競合ない場合、互いに衝突のように（であることができますデッドロック）は、後に導入されます。
しかし、すべての理想的な理想の後、すべての後に、リソースの消費をロックする必要があります。構成する各種操作ロック：ロックを取得し、ロックなど、ロックを解除し、解除されたかどうかをチェックし、システムのコストが増加します。システムがロックではなく、データへのアクセスを管理するために多くの時間がかかる場合、そのシステムの性能も影響を受けることになります。
あなたは、コストと安全ロックとの間のバランスを模索する必要があるので、。ほとんどの商用データベースシステムより多くの選択肢を提供していないが、一般的にロック例比較的多数で優れたパフォーマンスを提供するために、テーブルの上に行レベルロックを適用し、複雑なさまざまな方法でされています。しかし、MySQLはさまざまなオプションを提供しています、MySQLのストレージエンジンのそれぞれが独自の戦略とロックロックの粒度を実装することができます。
表ロック：（など、挿入、削除、変更、更新）テーブル全体を記述する前には書き込みロックが存在しないときにのみ、ロックされていたが、それぞれ他の読み取りロックをブロックしない、読み込みロックを取得するために、他のユーザーをお読みください。
行レベルロック：現在の運転行ロックの値。
表ロックは、最も低コスト戦略であるが、まだ同時実行上の非常に大きな制限は、特定のシナリオでは、テーブルロックにも優れた性能を有することができます。例えば、READ LOCAL表の特定の種類は、同時動作をサポートしています。さらに、読み取りロックより高い優先度よりも書き込みロックは、読み取りロックが書き込みロックの前方に挿入することができないのに対し、ライトロック要求は、読取りロックの前に挿入することができるように、存在します。テーブルロックの方が大きいシーンを書くのがより適していることができます。自分の管理ストレージエンジンのロックにもかかわらず、MySQLの自体はまだ異なった目的を達成するために有効なロックテーブルの様々なを使用します。例えば、サーバは、ストレージエンジンロック機構を無視して、テーブルのロック値のクラスを使用して、ALTER TABLE文のとおりです。
行レベルロックのInnoDBとXtraDBの行レベルのロックおよび他のいくつかのストレージエンジンを実現最大化するために同時処理をサポートすることができます。行レベルでのロックのストレージエンジン層のみ達成が、MySQLはサービス層を実装していません。
第二に、トランザクションのACID
トランザクションは、SQLクエリの原子の集合、又は作業の別個のユニットです。
文トランザクションのコンセプトを読むとき、あなたはまだビジネスが何であるかを知らないのでしょうか？なぜトランザクションを使うのか？トランザクション自体は、それが含まれているだけで、操作データの内容が、全体のプロセスの運用データの内容よりも多くを必要とする非常に複雑なプロセスであるためです。古典的なケースでの取引を見て見て前に：
銀行のデータベースのテーブル2と仮定すると：チェック（チェック）テーブルと貯蓄（貯金）のテーブル。彼女の貯金から$ 200のユーザの当座口座振替から今ジェーンはそれが、少なくとも3つのステップが必要となるアカウント：
1.以上$ 200の当座預金口座の残高を確認してください。
2.マイナス当座預金口座の残高から$ 200
3.貯蓄$ 200の増加がバランスを占めています。
手順通常の状況に応じて、この3つのSQLステートメントは、次の可能なシナリオを用いて、この機能を達成するために実行されるが、同時の前に、これらの二つのレコードを操作しながら、発生することがあり、ユーザーオープンプロセスの複数ことを知ることができます。
ケース1：ステップ1とステップ2では、他の同時ユーザー・プロセス間オンになっているのバランスを変更するには、状況のバランス未満$ 200表示され、この時間は必然的にステップ2失敗につながります。
ケース2：システムは、ステップ2の実装後にクラッシュし、ステップ3が達成されていない、これは必然的に$ 200のユーザー損失につながります。
ケース3は：ステップ2の実装後は、他のユーザーオープンなプロセスは、$ 200のジェーン・ホワイトにバンクを導く可能性がある、すべての当座預金口座の残高を削除します。
ここでは、一時的にこれらの問題を解決する方法を特定のデータベースシステムについては説明しませんが、実際の実装では、これはないブログを理解する必要がないこと、アプリケーション開発レベルから、はっきり話すことができるようになり、非常に複雑なデータストレージの問題ですこれらは、これらの問題の解決策は、アプリケーション開発レベルからの厳しい基準を持っているので、我々は唯一の標準溶液標準はシーンは、どのような状況下でどのような問題が生じる可能性があるものを適用する知っている必要があり、必要であり、応じて、事実上の標準とデータベースシステムとの私達は私達のデータベースを設計する方法を標準実現しています。
トランザクションへの3段階の一般的な場合は、これらの3つのステップは、厳密なテストACIDを通じてシステムがない限り、通常の実行完了できることを保証するものではありませんトランザクションを使用して実行されます。
ACID：データベーストランザクションの四つの基本的な要素が適切にそれぞれ実行手段（原子：原子性、一貫性：一貫性、分離：分離、永続性：耐久性）。
アトミック：トランザクションはロールバックの成功または失敗を提出いずれかで動作作業の不可分の単位、である、操作の一部を実行することは不可能です。例えば、ケースの場合には、ステップ2、ステップ3に失敗しないであろう。
一貫性：別の一貫した状態の一貫性のある状態からのデータベース総変換。例えば、ステップ2と3ベン・崩壊の間、システム内の2例の場合には、3本が達成される方法として、執行部に提出されることはありません段差がないため、アカウントをチェックすると、$ 200失うことはありません、後者の内容を説明します。
単離：最終提出する前に変更を加えるためにしっかりと、他のトランザクションは表示されません。例えば、ケースのステップ2が完了したが、まだステップ3に実装されていない、レコードを照会する別のユーザー・プロセスは、そのレコードクエリはマイナス$ 200に記録されていない、確認してください。しかし、これは、それが、後に詳細に説明するが、理論的には、それはトランザクション分離レベルに関係していると言うことができます。
耐久性：トランザクションがコミットされたら、それは修正恒久的に行われる彼らのデータベースに保存されました。そして、さえ私のシステムがクラッシュした場合、変更されたデータが失われることはありません。永続的な任意のコースは多くのレベルに分かれて、いくつかの永続化戦略は非常に強力なデータセキュリティすることができ、一部はないかもしれないが、持続性も比較的に言えば、またはデータのバックアップであり、それはどのような意義を持っていないので？
第三に、トランザクションログ
ログはデータベース・レコード・ファイル、レコードの挿入、更新、削除、コミット、ロールバック、およびデータベース・スキーマの変更への変更を保存するために使用されるトランザクションは、データのバックアップとリカバリの重要な構成要素であるだけでなく、SQLリモートまたは[コピーエージェント]は、データをコピーします必要に応じて。
言うことができる、トランザクション・ログは、トランザクションの基礎となる、トランザクションログ、それが何であるかを最終的には？トランザクションログが動作する方法ですか？
トランザクションログが含まれています：REDOログ（REDOログ）、アンドゥログ（ロールバックログ）は、ロググループ（ロググループ）。
REDOログ：MySQLのSQLステートメントのトランザクションがREDOログREDOログ・オペレーションに記録して、対応するデータファイルへの同期に操作に関与するすべてのデータになります。データベースファイル内のレコードを変更する前に、あなたはすべて、対応する変更操作がREDOログに記録されていることを確認しなければならないこと。REDOログ・バッファとのREDOファイルログ：REDOログは、2つの部分に分かれています。
- REDOログ・バッファ（REDOログ・バッファ）：ログライトバッファメモリ、ディスクに直接書かれていますが、ベンは、システムがデータの損失になります。この時間を折りたたむ場合は、メモリは、持続的な需要を満たすことができないよりもはるかに高速です。
- REDOログ・ファイル（REDOログ・ファイル）：REDOログ・ファイルはるかに遅いバッファREDOログに比べて、ログディスクに書き込まれますが、ログがディスクに書き込まれる持続性の基本的なニーズを保証することができます。
アカウントに性能と耐久性を取るためには、一般的には、最初のトランザクションログでメモリ（REDOログ・バッファ）に書き込まれ、その後、メモリ、ディスクIO操作は比較的はるかに遅い場合でも、ディスク（REDOログ・ファイル）に同期メモリをログに記録が、比較的データベースですなぜならREDOログ・ファイルの個別の書き込み、まだはるかに高速では、ディスク上の連続した領域です。記録動作がにログファイルを再実行する場合は、データベースのトランザクション全体のプロセスデータに書き込まれているデータベースファイルを再同期します。
REDOログ・ファイルへの書き込みデータへのREDOログ・バッファは、データの永続性を確保するために、これは大幅にパフォーマンスが低下しますが、ポリシーがinnodb_flush_log_at_trx_commitパラメータにより、REDOログ・バッファからREDOログ・ファイルを書かれている修正することができますが、それは持続を失うことになります抵抗は、書き込みポリシー、実際の状況に応じてトレードオフを磨くために、具体的方法、データを失うことが可能です。
物理的なREDOログ・ログ、検索、REDOログ・冪等で論理的な変更をデータベースのREDOログ・ページ動作に記録、および削除ではないとして。
アンドゥログ、トランザクションが途中で、SQLの実装を成功さのどの部分が存在しない、データベースはアンドゥログの下に取り消すことができる場合、ログは、データ変更の前にバックアップとして理解することができ、圧延前に修正するために、論理的にすべて変更されたデータを復元します：その後、方法、そのようなデータの前に挿入100、それらを削除し、アンドゥログに基づいてそれらを更新するための更新データ50は、したがって、アンドゥログが論理ログで、物理ページログのREDOログレコードの操作と異なる場合。
グループログ：REDOログ・グループは、複数のREDOログ、ログファイルがいっぱいになると、それはREDOログ・ファイル内の次のグループのログREDOログは、ログ・グループのすべてのREDOログに書き込まれるログ・グループが含まれていますこのファイルは、その後、REDOログを充填した後、元のREDOログを上書きし、最初のREDOログ・ファイルに書き込まれるので、新しいREDOログ・書き込みということです。デバイスがどこREDOログクラッシュした場合、ログは失われますやり直し、これは保証REDOログはすべての回で提供されていますされませんので、グループでもサポートされているが、一般的に冗長化機能を備えたログ・グループで、グループをミラーリングログログこのようradi1などのデバイス、上。
REDOログは、REDOログに格納されたアンドゥログ内部データベース特別なセグメントに格納され、このセグメントは、共有セグメントのUNDO表領域に位置アンドゥセグメント（セグメントアンドゥ）と呼ばれます。かかわらず、REDOログのか、データベースを回復するためにあらゆる手段をログ元に戻します。
MySQLの、InnoDBストレージエンジンがサポートする取引では、MyISAMストレージエンジンは、REDOログやアンドゥログ、すべてのInnoDBの製品に関係なく、トランザクションをサポートしていませんが、binlogのあるもう一つの重要なMySQLのバイナリログがある、それは時間のMySQLのですログに必要なマスター・スレーブレプリケーション環境ではなく、ストレージエンジンレベルのbinlogログは、MySQLデータベースのストレージエンジンはバイナリログデータベースに加えた変更を生成します。
ディスクへのredoログbinlogのタイミングと書き込みが異なる、InnoDBはトランザクションが実行されたときにのみ、トランザクションのコミットが完了した後、バイナリログターンディスク書き込みをREDOログのREDOログ・ファイルを書き続けます。
ビューInnoDBストレージエンジンのログ設定パラメータ：
表示さグローバルのような変数「％のInnoDB％ログ％を」
パラメータ説明ログは、このブログを参照することができ、特定：http://www.zsythink.net/archives/1216：缶についての詳しい情報は、公式ドキュメントを参照してくださいhttps://dev.mysql.com/doc/refman/5.7/エン/ InnoDBの-ストレージengine.html
第四に、トランザクション分離レベル
既に学習トランザクションログアトミックトランザクションに解決することができ、持続性、ACIDは不可欠な要素（分離）が関与していない左の事、そして分離は何ですか？なぜ我々は、分離、違いは何ですか分離レベルが必要なのでしょうか？
他のトランザクションの操作が分離されている内部トランザクション分離何かを意味し、互いに同時に実行様々なものを妨害することができません。
- READ UNCOMMITTED（非コミット読み取り）
- READがコミット（コミット読み取り）
- REPEATABLE READ（反復可能読み取り）
- SERIALIZABLE（直列化可能）
4.1：READ UNCOMMITTED（非コミット読み取り）
コミットされていないトランザクションを読んで、トランザクションがコミットされていない場合でも、データの修正を表し、他のトランザクションも表示されます。ユーザデータの演算処理が別のユーザー・プロセスのオープントランザクションBながら、トランザクションがデータ変更ステートメントを実行しますが、トランザクションが提出されていない、総務Aが開始されたと仮定し、Bのトランザクションただちに変更を実行するために行っただけの取引を読みますREAD UNCOMMITTED分離レベルでのデータは、データを読み取るだけ修飾トランザクションデータです。
READ UNCOMMITTEDのパフォーマンスの観点からあまり良く他のレベルよりも、本当にめったに使用しない必要がある場合を除き、他のレベルの利点の多くを欠いています。
ダーティリードは、SQLデータ変更ステートメントを実行しますが、取引上のデータが発生します提出するのではなく、実行することにより、データを読み込むときには、トランザクション・ロールバックの発生により提出されたデータを変更していない、どのなかった他のトランザクションを読んで意味するものではありませんダーティのみ知られて読んだときに、実際には、汚いことをいうが読み取られ、症例のデータベースに書き込まれた一貫性のないデータを読み出します。
4.2：READがコミット（コミット読み取り）
トランザクションが開始されると、我々は唯一の企業は変更が他のトランザクションに提出する前に、実行するすべての企業があることを、提出された作られた「見る」ことができます表示されません。二度同じクエリ内政に、異なる結果を得ることができますので、このレベルでは時々、非反復可能読み取りと呼ばれています。
4.3：REPEATABLE READ（反復可能読み取り）
同じレコード構造を読むために性を保証同じトランザクションが複数回というこのレベルは同じですが、理論的には、反復可能読み取り分離レベルは、別の問題ファントムリードを解決しません。
トランザクションが読み込みの範囲内に記録され、他のトランザクションと、この範囲内で新しいレコードを挿入し、トランザクションが再度読み込まれたレコードの範囲の前にするとき、それは仮想線（ファントム行）を生成します：マジック読書。マルチバージョン同時実行制御（MVCC、マルチバージョン同時実行制御）により、ファントムリードの問題を解決するためXtraDBとInnoDBストレージエンジン。
反復可能読み取りは、MySQLのデフォルトの分離レベルのものです。
4.4：SERIALIZABLE（シリアライズ）
Serializableの分離レベルは最高です。物事を強制することにより、シリアル実行は、ファントム読み取りの問題を回避することが以前に述べました。簡単に言えば、SERIALIZABLEはそれがタイムアウトとロック競合の多い問題を引き起こす可能性があり、読み込まれたデータの各行にロックを持つことになります。実用的なアプリケーションはほとんどのデータの一貫性を確保するために非常に必要で、この分離レベルを使用していないし、何も同時ケースを受け入れることはできない、唯一のそのレベルを考慮してください。
---------------------------------------
ANSI SQL分離レベル：
V.デッドロック
デッドロックは、二つ以上のものが悪循環の現象につながる、同じリソース、および他の占有リソースのロック要求にお互いを占有を指します。より多くの物事は異なる順序でリソースをロックするときは、デッドロックにつながる可能性があります。複数のトランザクションが同時に同じリソースをロックするときは、デッドロックを生成します。このような、次の例のように：
トランザクション1：
start transaction ; update t_employee set sal=5000 where ename='JONES'; update t_employee set sal=4500 where ename='BLAKE'; commit ;
事务2：
start transaction ; update t_employee set sal=6000 where ename='BLAKE'; update t_employee set sal=3800 where ename='JONES'; commit ;
可以尝试启动两个控制台进入数据库然后按照以下顺序执行语句：
执行到第三步时，两个进程都会等待一会儿，然后报超时错误：
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
为了解决死锁的问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。除了这种解决方法以外就是当查询达到锁超时的设定后放弃锁请求，这种方式不太友好。InnoDB目前处理死锁的方法是，将有最少行级排他锁的事务进行回滚。
锁的行为和顺序是和存储引擎相关的，以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些则完全是由于存储引擎的实现方式导致。
上面示例测试的表事务隔离级是REPEATABLE READ，存储引擎是InnoDB。
关于死锁更详细的解析和解决方案可以参考这篇博客：https://blog.csdn.net/qq_36132127/article/details/81272293
六、MVCC
MVCC全称Multi-Version Concurrency Control，即多版本并发控制协议。MySQL的大多数事务型存储引擎都不是简单的行级锁，为了提升并发性能的，它们一般都同时实现了并发控制。而且不仅仅是MySQL，包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC，但各自的实现机制不尽相同，因为MVCC没有统一的实现标准。
MVCC很多情况下避免了枷锁操作，因此开销更低。虽然实现机制不同，但大都实现了非阻塞的读操作。写也只锁定必要的行。MVCC是通过保存数据在某个时间点的快照来实现，不管一个事务要执行多长时间，事务内部每个时间点看到的数据都是一致的。
前面说过MVCC在不同存储引擎实现是不同的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。
InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的，这两个列分别保存行的创建时间和过期时间（或称为“删除时间”）。而且存储并不是实际时间值，而是系统版本号（system version number）。下面来看看InnoDB的SQL操实际是如何来操作这两个隐藏列的：
INSERT ：为新插入的每一行保存当前系统版本号作为行的版本号。
DELETE：为删除的每一行保存当前系统版本号作为行的删除标示。
UPDATE：插入一行新的记录，保存当前系统版本号作为行的版本号，同时保存当前系统版本号到原来的行作为删除标识。（也就是说修改数据实际上是新增一行记录，删除原来的记录）。
SELECT：查找版本早于或等于当前事务版本号的数据行，并且删除把呢不能还未定义。意思就是查找早于当前事务版本的记录，这是在事务内部未对查找的记录删除或修改；如果在查询前当前事务新增的记录是可以被查询到的，在查询前事务内部修改的记录也是可以查询到的，查询前事务内部的删除也可以被查看到。
根据上面的说明，也就是说可重复读并不意味着在事物内部两次相同的读语句可以完全获得相同的结果。
六、MySQL的事务
在MySQL中默认情况下，每一条SQL语句都当作一个单语句事务，并默认自动提交，可以通过下列语句查看全局和当前会话是否开启自动提交功能。
show global variables like 'autocommit%'; show session variables like 'autocommit%';
并且可以手动关闭当前会话的默认提交：
set autocommit=0;
如果手动关闭了默认提交，执行SQL数据操作语句后就需要手动使用commit提交。
除了默认SQL语句自动默认采用事务机制，可以通过手动开启事务并提交，下面是MySQL事务控制语句的语法：
START TRANSACTION | BEGIN [work] COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
START TRANSACTION 或BEGIN：表示开启一个事务。当由于在存储过程中BEGIN END作为SQL语句的包裹关键字，所以为了区分一般使用START TRANSACTION作为事务开启语句。
COMMIT或COMMIT WORK：表示提交事务。也就是说START TRANSACTION 与COMMIT之间的SQL语句对数据的操作称为永久性操作。
ROLLBACK或ROLLBACK WORK：表示事务回滚。也就是撤销事务中在回滚语句之前的数据操作，之后的数据不会被撤销，这一点需要注意。
除了以上三个语句以外，还可以使用标识符用来控制回滚。
SAVEPOINT #表示创建标识符 ROLLBACK TO SAVEPOINT#表示回滚到这个标识符的记录 RELEASE SAVEPOINT #表示删除一个保存点
本来想着写一个示例，但是在感觉没有这个必要了，如果需要的话可以参考下面这两篇博客：