START TRANSACTION;
...
COMMIT; -- ROLLBACK; -
定義について
トランザクション性と関係性の定義とは、まず、 FKを介したテーブルの完全な接続を意味し、その結果、行を削除する際のデータの整合性を意味します。 MyIsamでは、ご存知のように、複数のテーブルの関連データを手動で削除する必要がありました; InnoDBでは、単一のクエリによるカスケード削除。 第二に、SVNのようなデータの並列バージョンはデータベースでは考えられないため、これらのバージョンを1つのブランチにまとめることはできませんが、同じデータを持つ複数のプロセス（ユーザー）の並列作業が必要な場合、トランザクションがソリューションになります。
request-carキューは、アトミックバストランザクションで補充されるようになりました。 当然、トランザクションが実行される時間が長くなるほど、より多くの並列プロセスが待機するため、これは悪いことです。 作業を高速化するために、停止が作成されます-データブロックの種類とレベル。 InnoDBのデフォルトでは、これは行レベルのロック（ PK ）ですが、MyIsamでは、アトミック操作がテーブル全体をロックします。
トランザクション=ロック
したがって、2つのエンジンを比較することはできません。2つのプロセスの同じ行へのキューの確率が低いため、トランザクションの性質上、InnoDBは行レベルまで下がる必要があります。 ただし、その結果、各行にロックフラグを作成する必要があります。これは、メモリが少し増えることを意味します。 データブロックレベルの違いにより、InnoDBとMyIsamをプロセス数に応じたパフォーマンスの観点から比較することは非常に困難です。
ロックにはいくつかのタイプがあります。
- READ（読み取り中-誰も書き込みません）-デフォルトでは、SELECTが設定されています
- WRITE（書き込み中-誰も読み書きしない）-デフォルトでは、UPDATEが設定されます
- LOW_PRIORITY WRITE（誰かが待機している場合は簡単に読み上げます）
教育プログラムとして、テーブル全体を手動でブロックできます（ただし、InnoDBの場合はすべてのプロセスが悲惨なほど遅くなるため、不要です）。 再ロックすると、以前のロックが削除されます。 仮想テーブル（ビュー）をブロックすることもできます
LOCK TABLES user WRITE, company READ;
UNLOCK TABLES;
分離レベル
2つのプロセスが同時にかつ部分的に共通データに影響を与える場合、すべてのデータが完全にブロックされるわけではありません。 並行トランザクションが保留中のトランザクションにアクセスする場合、免除があります。
現在のレベルは、設定から取得したり、設定に登録したり、リクエストによって実行したりできます-トランザクションの期間と接続全体の期間の両方。
SELECT @@global.tx_isolation;
SET TRANSACTION ISOLATION LEVEL READ COMMITED;
SQL92標準に従って降順での正確度（ロックの厳密さ）に応じて、以下があります。
- シリアライズ可能-完全なトランザクションの独立性を含む あなたの読書
- REPEATABLE READ-InnoDBのデフォルト値。 トランザクション内の共通行の読み取りは許可されていますが、変更はできません。
- READ COMMITED（読み取り固定）-書き込みロックですが、一般的な読み取り。 繰り返し読むという問題があります。 最初のトランザクションでは、2番目のトランザクションで一般データが変更されるため、一般的なデータはさまざまな方法で数回読み取られます。
- READ UNCOMMITED（コミットされていない「ダーティ」な読み取り）-読み取りおよび書き込みのブロックなし。 2つの同時UPDATEでは、フィールドは両方のトランザクションの最後の変更の値を受け取ります。 特に、ROLLBACKの前に1つのトランザクションが別のトランザクションを読み取る場合、多くの問題が発生します。
REPEATABLE READにファントム挿入の問題があります。 UPDATEの行のみがブロックされ、INSERTの行はブロックされないため、繰り返し読み取りトランザクションと並行して挿入を行うことができます。これにより、幻の行が生成されます。 これを回避するために、InnoDBは3つのロック方法を使用します-行、範囲、および挿入の場合の次の行（より深い読みはしませんでした）
この理論全体は確かに有用ですが、実際には実際の要求によって使用されます。
- REPEATABLE READレベルでの読み取り（書き込みロック）。 誰かがデータに取り組んでいる場合は待機しています。
SELECT... LOCK IN SHARE MODE
- SERIALIZEABLEモードでの読み取り（読み取り/書き込みロック）
SELECT... FOR UPDATE
トランザクションの継続中のこれらの要求により、新しいモードに入ります。
デッドロック傷害
デッドロック、つまり プログラミングでは、同じデータを必要とする、または互いに依存する同時プロセス（スレッド）のデッドロックがしばしば発生します。 InnoDBも例外ではありません。 たとえば、進行中のトランザクションが2つあり、それぞれが現在ロックされているリソース（行/行の範囲）を変更する場合です。 トランザクションを終了できないことが判明しました。
そのような状況では、InnoDBはトランザクションの1つをロールバックし、エラーをスローするように強制されます
ERROR 1213 (40001): Deadlock found when trying to get lock; try
restarting transaction
このような問題は、複数のプロセスによる行の大規模な並列挿入/変更/削除で発生します。 MySQL は、すべてのトランザクションにトランザクションの再実行を装備することをお勧めします。
トピックについて..
- 2007年のMyIsamとInnoDBの負荷の比較
- 参照整合性
オリジナル記事