トランザクションの説明：
MySQLではのみ使用のInnoDBデータベースエンジンやデータベースのテーブルをトランザクションのみをサポートします。トランザクションは、SQL文の大部分は、いずれかのすべての実行またはすべての実行されないことを保証するために、データベースの整合性を維持するために使用することができます。また、挿入、更新、削除のステートメントとして総務DDL、DML、DCL操作を管理するために使用することができます。一般的に言って、トランザクションが4つの条件（ACID）を満たしている必要があります。
アトミック（原子性）：
トランザクションまでのすべての操作は、論理ユニット、すべての実行またはすべての実行されないのどちらかでなければなりません
一貫性（安定性、一貫性）：
トランザクション実行状態の前と後のデータベースが安定しており、一貫している必要があります。
分離（隔離）：
トランザクションがお互いに影響を与えません。
耐久性（信頼性、耐久性）：
トランザクションの実装を成功した後、完全にディスクに書き込む必要があります。
約3一般的な操作があります：
BEGINあるいはSTART TRANSACTION ;トランザクションを明示的に開きます。
トランザクションを閉じます。
COMMIT ;また、COMMIT WORKを使用するが、両者は等価であることができます。トランザクションをコミットCOMMIT、およびデータベースは永久的なすべての変更を呼びかけています。
ROLLBACKは、ROLLBACK作業を用いることができるが、両者は等価です。ロールバックエンドユーザー・トランザクションと進行中のコミットされていないすべての変更を撤回します。
MySQLのコマンドラインでは、デフォルトの設定は、トランザクションがされて自動的に提出されているが、SQL文は操作が直ちに実行されますCOMMITを実行することです後。したがって、するトランザクションを明示的に開くことはすることをお勧めSETをBEGINコマンドを使用するか、START TRANSACTION、またはAUTOCOMMIT = 0を実行し、現在のセッションを使用して自動送信を無効にするには、。
トランザクションの同時実行：
問題では同時動作いくつかの問題ことがあります
ダーティ読み取り：トランザクションが別のコミットされていないトランザクションにデータを読み込みます。
非反復可能読み取り：ので、別のトランザクションを読み込むためのトランザクションデータが送信されました。矛盾の記録読書と倍以上の結果が得られ。更新操作
ファントムを読む：ので、トランザクションが別のトランザクションを読み取るために、データが送信されました。同じテーブルの矛盾の結果の2倍以上読書をもたらし。挿入、削除操作
トランザクションの隔離：
発生するトランザクションの同時実行の問題を回避するためには、標準のSQL計画、異なるトランザクションのためのさまざまな分離レベルの4つのトランザクション分離レベルを定義します。
ローからハイへ：
① READ UNCOMMITTED（非コミット読み取り）：最低のレベルは、どのような場合には保証できません。
② 読み取りコミット（読み取りコミット）：汚れが発生するの読み込みを避けることができます。
③ 反復可能読み取り（反復可能読み取り）：ダーティリード防ぐことができ、またとないが発生して読み取ります。
④ 直列化（シリアル化）：ダーティ・リード防ぐことができ、非反復リード、ファントムリードが発生します。
ほとんどのデータベースのデフォルトの分離レベルは、読み取りなど、コミットオラクル、その上のDB2と。
MySQLデータベースのデフォルトの分離レベルはある反復可能読み取り。
現在のトランザクション・レベルを表示します。
@@ tx_isolationを選択します。
トランザクション分離レベルを設定します。
セット[glogal |セッション]トランザクション分離レベル分離レベル名。
=「名前分離レベルセットtx_isolation ;」
分離レベルが高いほど、それがデータの整合性と一貫性を確保することができるが、同時パフォーマンスへの影響も大きいです。
ほとんどのアプリケーションでは、データベース・システムは、コミット読み取りに分離レベルを優先することができます。ダーティリード防止することが可能ですが、また、より優れた同時実行性能を有しています。それは非反復可能読み取りにつながるが、ファントムは、これらの並行性の問題を読んで、そのような問題が発生する可能性があり、個々のケースでは、アプリケーションはコントロールに排他的ロックまたはオプティミスティック・ロックを使用して作製することができます。
MySQLのロック：
独自のMySQLデータベースアーキテクチャ、データストレージエンジンの様々ながあり、各アプリケーションシナリオのストレージエンジン特性れるそれらの特定のアプリケーションシナリオのニーズを満たすために、同じではない、各ストレージエンジンロック機構は、ためのものです各ストレージエンジンのロック機構も、かなり異なっているように、各顔の特定のシーンとは、デザインを最適化する、一般的には：ロック機構のMySQLストレージエンジンそれぞれ使用する3つのタイプ（レベル）行レベルロック、ページレベルのロックとテーブルレベルのロック。私たちが最初に分析してみましょうそれぞれのMySQLの3ロック機能や長所と短所を。
行レベルロック（ローレベル）。
行レベルの最大の機能をロックするオブジェクトをロックすることで非常に小さな粒子である、現在の最小粒度を達成するために、主要なデータベース管理ソフトウェアでロックされています。ロック粒度が小さいため発生ロックされたリソースの競合の確率が最小であるように、アプリケーションは、同時処理能力の最大の可能な数を与え、高い全体的なシステム性能を必要とする同時アプリケーションを向上させることができます。それは上記の同時処理能力に大きな利点を有するが、多くの欠点を持って行レベルのロックができるにもかかわらず。たびに物事が取得して、ロックの粒度の小さな資源ので、リリースロックも当然大きいの消費をもたらすために、より行う必要があります。加えて、行レベルのロックはまた、デッドロックが最も生じやすいです。
テーブルレベルロック（表レベル）
その代わりに、ロック行レベルは、テーブルレベルのロックは、ロック機構の各最大粒度にMySQLのストレージエンジンです。ロック機構の最大の特徴は、ロジックは非常に単純で実装することである、システム上の最小の負の影響をもたらします。だから、ロックを取得し、すぐにロックを解除します。テーブルレベルのロックのためには、テーブル全体をロックします、私たちを苦しめるデッドロックを回避するために良いことができます。もちろん、最大のロック競合リソースロック大きな粒子の確率は、負の影響の出現が大幅に減少し、寛大で得られた、最高であろうあります。
MySQLのテーブルレベルのロックは、2つのモードがあります。共有テーブルがロック（読み表リードロック）と、テーブルの排他書き込みロック（表書き込みロック）。
table_locks_immediate：周波数発生テーブルレベルのロック。
table_locks_waited：テーブルレベルのロックは時間が競合を発生待って表示されます。
手動でテーブルロックを増やします：
ロック表表の名前読み取り（書き込み）、テーブルの名前2 リード（ライト）、その他;
ビューテーブルのロック状況：
示しオープンテーブルを。
削除するには、テーブルロック：
ロック解除のテーブル;
ページレベルロック（ページ・レベル）：
MySQLでのページレベルのロックは、あまりにも一般的ではありません、他のデータベース管理ソフトウェアでは、比較的ユニークなロックレベルです。ページレベルロック粒度ロックは行レベルロックテーブルレベルロックとの間に備え、ロックオーバーヘッドリソースを取得するために必要とされ、同時処理を提供することができ、また2以上の間に介在されています。また、ページレベルのロックと行レベルのロック、デッドロックが発生しています。
テーブルレベルロック：小さなオーバーヘッド、高速ロック、デッドロックしない、ロック大きいサイズ、並行性の最高、最低度のロック競合の確率。
行レベルのロッキング：大きなオーバーヘッドが、低速ロック、ロック粒度最小とロック競合の最も低い確率だけでなく、並行性の最高度、デッドロックが存在するであろう。
ページロック：テーブルと行ロックの間のオーバーヘッド及び時間境界をロックは、一般に粒度テーブルと行ロックの境界、同時実行をロック、デッドロックが存在することになります。
InnoDBエンジンロック機構
InnoDBの行ロックはので、インデックス・ロックのインデックスエントリを与えることによって達成され、この特性の手段を達成するためのInnoDB行ロック：、インデックスのみの条件を介してデータを取得する。InnoDBは唯一の行レベルのロックをそうでない場合は、InnoDBはテーブルロックを使用します！。
InnoDBテーブルの行レベルのロックは、2つのタイプに分けられる共有ロックと排他ロック、および行レベルのロックとテーブル・レベルのロッキング共存を可能にするために、実装プロセスのロック機構では、InnoDBはまた、意図的ロック（表レベルのロック）を使用しますコンセプトは、私たちは持っていますロックと意図排他ロック共有の意思の両方を。
使用INNODB行レベルのロック状態表示方法：「innodb_row_lockの％」のような表示状態。
* Innodb_row_lock_current_waits：現在ロックの数を待っています。
* Innodb_row_lock_time：ロッキングシステムの合計時間の長さから、今スタート。
* Innodb_row_lock_time_avg：時間を待っている時間の平均。
* Innodb_row_lock_time_max：今、ほとんどの時間を費やした待機時間にシステムから始めます。
* Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是：
Innodb_row_lock_time_avg（等待平均时长）
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。