MySQL トランザクションログを一緒に分析しましょう-mysql チュートリアル-php.cn

この記事では、mysql に関する関連知識を提供します。主に mysql トランザクションの関連問題を紹介します。トランザクションは、MySQL と NoSQL を区別し、リレーショナルデータベースデータを保証する重要な機能です。一貫性の主要なテクノロジ、皆様のお役に立てれば幸いです。

MySQL トランザクションログを一緒に分析しましょう

推奨される学習: mysql 学習ビデオチュートリアル

1. MySQL トランザクション

トランザクションは、MySQL と MySQL を区別するものです。 NoSQL 重要な機能は、リレーショナルデータベースのデータの一貫性を確保するための主要なテクノロジです。トランザクションはデータベース操作の基本的な実行単位とみなすことができ、これには 1 つ以上の SQL ステートメントが含まれる場合があります。これらのステートメントが実行されると、すべてが実行されるか、まったく実行されません。

トランザクションの実行には、主にコミットとロールバックの 2 つの操作が含まれます。

送信: コミットし、トランザクションの実行結果をデータベースに書き込みます。

ロールバック: ロールバック、実行されたすべてのステートメントをロールバックし、変更前のデータを返します。

MySQL トランザクションには、4 つの ACID キングとして知られる 4 つの特性が含まれています。

原子性: ステートメントは完全に実行されるか、まったく実行されません。これはトランザクションの中核機能です。トランザクション自体は原子性によって定義され、実装は主に UNDO ログに基づいています。

Durability (永続性): トランザクション送信後のダウンタイムなどでデータが失われないことを保証します。主に REDO ログに基づいて実装されます。トランザクションの実行は可能な限り可能です他のトランザクションの影響を受けません; InnoDB のデフォルトの分離レベルは RR です。RR の実装は主に、ロックメカニズム、データの非表示列、元に戻すログ、ネクストキーロックメカニズムに基づいています。

一貫性: トランザクション追求される最終目標である一貫性の実現には、データベースレベルとアプリケーションレベルの両方での保証が必要です。トランザクションアトミック操作と同様に、トランザクションをさらに分割できないことを意味します。すべての操作が完了するか、まったく操作が完了しないかのどちらかです。トランザクション内の SQL ステートメントの実行に失敗した場合、実行されたステートメントもロールバックする必要があります。、データベースはトランザクション前の状態に戻ります。0 と 1 のみで、他の値はありません。

トランザクションのアトミック性は、トランザクションが全体であることを示します。トランザクションが正常に実行できない場合、すべてトランザクション内で実行されたステートメントはロールバックする必要があるため、データベースはトランザクションが最初に開始されていない状態に戻ります。

トランザクションのアトミック性は、UNDO ログによって実現されます。トランザクションをロールバックする必要がある場合、InnoDB エンジンは SQL ステートメントを元に戻すために undo ログを呼び出します。データロールバック。

永続性

トランザクションの耐久性とは、トランザクションがコミットされると、データベースの変更は一時的ではなく永続的になる必要があります。これは、トランザクションがコミットされた後は、他の操作やシステムのダウンタイムであっても、元のトランザクションの実行結果に影響を与えないことを意味します。トランザクションの処理は、InnoDB ストレージエンジンを介して実行されます。REDO ログが実装されます。具体的な実装アイデアについては、以下を参照してください。

分離

アトミック性と耐久性は、単一トランザクション自体のプロパティです。 , 一方、分離はトランザクション間で維持されるべき関係を指します。分離では、異なるトランザクションの影響が互いに干渉せず、1 つのトランザクションの操作が他のトランザクションから分離されることが必要です。トランザクションには SQL ステートメントが 1 つだけ含まれているわけではないため、トランザクションの実行中に他のトランザクションの実行が開始される可能性が非常に高くなります。したがって、複数のトランザクションの同時実行には、トランザクション間の操作が互いに分離されている必要があります。これは多少似ています。

ロックメカニズム

トランザクション間の分離は、ロックメカニズムを通じて実現されます。トランザクションが特定の行を変更する必要がある場合データベース内のデータが大きい場合は、最初にデータをロックする必要があります。他のトランザクションは、ロックされたデータに対して操作を実行せず、現在のトランザクションがコミットまたはロールバックしてロックを解放するのを待つだけです。多くのシナリオでは、データの保護と同期のためにさまざまなロックの実装が使用されます。 MySQL では、ロックはさまざまな分割基準に従ってさまざまなタイプに分割することもできます。

粒度に応じて分割: 行ロック、テーブルロック、ページロック

用途に応じて分割: 共有ロック、排他ロック

アイデアに応じて分割: 悲観的lock 、 Optimistic locking

ロック機構については多くの知識点がありますが、スペースの都合上、すべて説明します。ここでは、粒度に従って分割されたロックについて簡単に紹介します。

粒度: データウェアハウスのデータユニットに保存されているデータの精製度または包括性のレベルを指します。精製度が高いほど粒度は小さくなり、逆に精製度が低いほど粒度は大きくなります。

MySQL は、ロックの粒度に応じて行ロック、テーブルロック、ページロックに分類できます。

行ロック: 最小粒度のロック。現在の操作の行のみがロックされていることを示します。

テーブルロック:最大粒度。現在の操作がテーブル全体をロックしていることを示します。

ページロック: 行レベルのロックとテーブルレベルのロックの間の粒度を持つロック。つまり、ページをロックします。

#データベースの粒度の分割

これら 3 種類のロックは、異なるレベルでデータをロックします。粒度が異なるため、次のような利点がもたらされます。デメリットも異なります。

テーブルロックはデータ操作時にテーブル全体をロックするため、同時実行パフォーマンスが低下します。
行ロックは、操作が必要なデータのみをロックするため、同時実行パフォーマンスは低下します。良い。ただし、ロック自体がリソースを消費するため (ロックの取得、ロックの確認、ロックの解放などはすべてリソースを消費します)、ロックされたデータが多い場合にはテーブルロックを使用するとリソースを大幅に節約できます。

MySQL のさまざまなストレージエンジンは、さまざまなロックをサポートできます。 MyIsam はテーブルロックのみをサポートしますが、InnoDB はテーブルロックと行ロックの両方をサポートします。パフォーマンス上の理由から、ほとんどの場合、行ロックが使用されます。

同時読み取りと書き込みの問題

MySQL の同時読み取りと書き込みにより、ダーティリード、非再現性、ファントム読み取りという 3 種類の問題が発生する可能性があります。。

(1) ダーティ読み取り: 現在のトランザクションは、他のトランザクションからコミットされていないデータ、つまりダーティデータを読み取ります。

上の図を例にとると、トランザクション A が記事の閲覧量を読み取るときに、トランザクション B によって送信されたデータを読み取ります。最終的にトランザクション B が正常に送信されず、トランザクションがロールバックされた場合、読み取り量は実際には正常に変更されませんが、トランザクション A は変更された値を読み取ります。これは明らかに不合理です。

(2) 反復不可読み取り: トランザクション A で同じデータが 2 回読み取られますが、2 回の読み取り結果は異なります。ダーティリードとノンリピータブルリードの違いは、前者は他のトランザクションによってコミットされていないデータを読み取るのに対し、後者は他のトランザクションによって送信されたデータを読み取ることです。

#上図は一例で、トランザクションAが記事閲覧データを次々と読み込むと結果が異なります。これは、トランザクション A の実行中に、他のトランザクションによって読み取りボリュームの値が変更されたことを意味します。これにより、データクエリの結果は信頼できなくなり、非現実的になります。

(3) ファントムリーディング: トランザクション A において、ある条件に従って 2 回データベースにクエリが実行され、2 つのクエリ結果の行数が異なる現象をファントムリーディングと呼びます。 Non-Repeatable Read と Phantom Read の違いは、前者はデータが変更されたことを意味し、後者はデータの行数が変更されたことを意味すると簡単に理解できます。

上の図は例で、0

分離レベル

上記の 3 つの問題に基づいて、データベースの分離特性の異なる程度を示す 4 つの分離レベルが生成されました。

実際のデータベース設計では、分離レベルが高くなるほどデータベースの同時実行効率が低下し、分離レベルが低すぎると、データベースの読み取りおよび書き込みプロセス中にエラーが発生すると、あらゆる種類のやっかいな問題が発生します。

したがって、ほとんどのデータベースシステムでは、デフォルトの分離レベルはコミット読み取り (Oracle など) または反復読み取り RR (MySQL の InnoDB エンジン) です。

MVCC

またしても噛み砕くのが難しい大きな作品。 MVCC は、RR を繰り返し読み取ることができる上記の 3 番目の分離レベルを実装するために使用されます。

MVCC: マルチバージョン同時実行制御、マルチバージョン同時実行制御プロトコル。

MVCC の特徴は、異なるトランザクションで異なるバージョンのデータを同時に読み取ることができるため、ダーティリードや反復不可能な読み取りの問題が解決されることです。

MVCC は実際に、データの非表示列とロールバックログ (UNDO ログ) を通じて、複数のバージョンのデータの共存を実現します。この利点は、MVCC を使用してデータを読み取るときにロックする必要がないため、同時読み取りと書き込みの競合が回避されることです。

MVCC を実装すると、バージョン番号、現在の行が作成されたときの削除時刻、UNDO ログへのロールバックポインタなど、いくつかの追加の非表示列がデータの各行に保存されます。ここでのバージョン番号は実際の時間値ではなく、システムのバージョン番号です。新しいトランザクションが開始されるたびに、システムのバージョン番号が自動的に増加します。トランザクションの開始時のシステムバージョン番号はトランザクションのバージョン番号として使用され、クエリ内のレコードの各行のバージョン番号と比較するために使用されます。

各トランザクションには独自のバージョン番号があるため、トランザクション内でデータ操作が実行されるとき、バージョン番号の比較によってデータのバージョン管理の目的が達成されます。

さらに、InnoDB によって実装された分離レベル RR は、ネクストキーロックメカニズムによって実現されるファントム読み取り現象を回避できます。

ネクストキーロックは実際には行ロックの一種ですが、現在の行レコード自体をロックするだけでなく、範囲もロックします。たとえば、上記のファントムリーディングの例では、0

ギャップロック: インデックスレコードのギャップをブロックします。

InnoDB はファントムリードの問題を回避するためにネクストキーロックを使用しますが、これは真にシリアル化可能な分離ではありません。別の例を見てみましょう。

最初に質問します:

トランザクション A がトランザクションをコミットした後の T6 時点で、記事 A と記事 B の読書量を推測します。いくらですか？

答えは、記事 AB の閲覧数が 10,000 に変更されたことです。これは、トランザクション B の送信が実際にトランザクション A の実行に影響を与えることを意味し、2 つのトランザクションが完全に分離されていないことを示しています。ファントムリード現象は回避できますが、シリアル化できるレベルには達しません。

これは、ダーティリード、反復不可能なリード、ファントムリードを回避することが、シリアル化可能な分離レベルを達成するために必要な条件ではあるが、十分な条件ではないことも示しています。シリアル化可能性により、ダーティリード、ノンリピータブルリード、ファントムリードを回避できますが、ダーティリード、ノンリピータブルリード、ファントムリードを回避しても必ずしもシリアル化可能性が実現するとは限りません。

一貫性

一貫性とは、トランザクションの実行後、データベースの整合性制約が破壊されず、トランザクションの実行前後のデータ状態が正当であることを意味します。実行されました。

一貫性はトランザクションによって追求される究極の目標であり、実際にはデータベース状態の一貫性を確保するために原子性、耐久性、分離性が存在します。

これ以上は言いません。丁寧に味わっていただきます。

2. MySQL ログシステム

MySQL の基本構造を理解すると、通常、MySQL の実行プロセスをより明確に理解できるようになります。次にロギングシステムについて紹介します。

MySQL ログシステムはデータベースの重要なコンポーネントであり、データベースの更新と変更を記録するために使用されます。データベースに障害が発生した場合、別のログレコードを通じてデータベースの元のデータを復元できます。したがって、実際には、ログシステムが MySQL 操作の堅牢性と堅牢性を直接決定します。

MySQL には、バイナリログ (binlog)、エラーログ、クエリログ、スロークエリログなど、多くの種類のログがあります。さらに、InnoDB ストレージエンジンは、次の 2 種類のログも提供します。REDO ログ ( redo ログ）と undo ログ（ロールバックログ）。ここでは InnoDB エンジンに焦点を当て、REDO ログ、ロールバックログ、バイナリログの 3 種類を分析します。

Redo ログ (redo ログ)

REDO ログ (redo ログ) は、InnoDB エンジン層のログであり、原因となったデータの変更を記録するために使用されます。トランザクション操作による、データページの物理的な変更です。

日記のやり直し機能は実はわかりやすいので例えてみましょう。データベース内のデータの変更は、自分で書いた論文のようなものですが、ある日その論文を紛失してしまったらどうなるでしょうか?このような不幸な出来事を防ぐために、論文を書くときに、すべての変更を記録する小さなノートを用意し、特定のページにいつ、どのような変更が加えられたかを記録することができます。これはやり直しログです。

InnoDB エンジンは、最初に更新レコードを REDO ログに書き込み、次にシステムがアイドル状態のときまたは設定された更新戦略に従ってログの内容をディスクに更新することによってデータを更新します。これはいわゆる先行書き込み技術 (Write Ahead ロギング) です。このテクノロジーにより、IO 操作の頻度が大幅に削減され、データ更新の効率が向上します。

ダーティデータフラッシュ

REDOログのサイズは固定であることに注意してください.更新レコードを継続的に書き込むために、REDOでは2つのフラグ位置が設定されますログには、checkpoint と write_pos があり、それぞれ消去が記録された位置と書き込みが記録された位置を示します。 REDO ログのデータ書き込み図を次の図に示します。

write_pos マークがログの末尾に達すると、ログの末尾から先頭にジャンプして再循環書き込みを行います。したがって、REDO ログの論理構造は直線的ではなく、循環運動とみなすことができます。 write_pos と Checkpoint の間のスペースは新しいデータの書き込みに使用でき、書き込みと消去は 1 サイクル内で前後に実行されます。

write_pos がチェックポイントに追いつくと、REDO ログがいっぱいになったことを意味します。現時点では、新しいデータベース更新ステートメントを実行し続けることはできません。最初にいくつかのレコードを停止して削除し、チェックポイントルールを実行して書き込み可能な領域を解放する必要があります。

チェックポイントルール: チェックポイントがトリガーされた後、バッファ内のダーティデータページとダーティログページの両方をディスクにフラッシュします。

ダーティデータ: ディスクにフラッシュされていないメモリ内のデータを指します。

REDO ログの最も重要な概念はバッファプールです。これはメモリ内に割り当てられる領域であり、データベースにアクセスするためのバッファとしてディスク内の一部のデータページのマッピングが含まれます。

データの読み取りをリクエストすると、まずバッファプールにヒットがあるかどうかが判断され、ミスがあった場合は、ディスク上でデータが取得され、バッファプールに置かれます。

##データの書き込み要求が行われると、まずそのデータがバッファープールに書き込まれ、バッファープール内の変更されたデータが定期的にディスクに更新されます。このプロセスはブラッシングとも呼ばれます。

したがって、データが変更されると、バッファープール内のデータの変更に加えて、操作が REDO ログにも記録され、トランザクションが送信されるとデータがフラッシュされます。 REDO ログレコードに基づくプレート。 MySQL がダウンした場合でも、再起動時に REDO ログ内のデータを読み取ってデータベースを復元できるため、トランザクションの耐久性が確保され、データベースのクラッシュセーフ機能が得られます。

ダーティログのフラッシュ

上記のダーティデータのフラッシュに加えて、実際には、REDO ログが記録されるときに、ログファイルを作成するには、ログレコードをメモリからディスクに書き込むプロセスも実行する必要があります。 REDO ログのログは、揮発性メモリ上に存在するキャッシュログ REDO ログ buff と、ディスク上に保存された REDO ログファイル REDO ログファイルの 2 つに分けられます。

各レコードをディスク上のログに確実に書き込むために、REDO ログバッファ内のログが REDO ログファイルに書き込まれるたびに、オペレーティングシステムの fsync 操作が呼び出されます。

fsync 関数: UNIX システムヘッダーファイル #include に含まれており、メモリ内で変更されたすべてのファイルデータをストレージデバイスに同期するために使用されます。

書き込みプロセス中に、オペレーティングシステムのカーネル空間の OS バッファも通過する必要があります。 REDO ログの書き込みプロセスを次の図に示します。

REDO ログフラッシュプロセス

バイナリログ (binlog)

バイナリログ binlog はサービス層です。ログはアーカイブログとも呼ばれます。 Binlog は主に、データベースのすべての更新操作を含む、データベース内の変更を記録します。データ変更を伴うすべての操作はバイナリログに記録する必要があります。したがって、binlog はデータのコピーとバックアップが簡単にできるため、マスター/スレーブライブラリの同期によく使用されます。

ここで binlog に保存されている内容は、REDO ログに非常に似ているように見えますが、そうではありません。 REDO ログは特定のデータに対する実際の変更を記録する物理ログですが、binlog は SQL ステートメントの元のロジックを記録する論理ログです。たとえば、「ID=2 の行のフィールドを指定する」などです。プラス1」。 binlog ログの内容はバイナリであり、ログ形式パラメータに応じて、SQL ステートメント、データ自体、またはその 2 つの混合に基づく場合があります。一般によく使用されるレコードは SQL ステートメントです。

ここでの物理と論理の概念についての私の個人的な理解は次のとおりです:

物理ログは、実際のデータベースのデータページの変更情報とみなすことができ、「どのような方法でこの結果になったか」は重要ではなく、
論理ログとは、ある方法や操作方法によるデータの変化とみなして、論理的な操作を記録したものです。

同時に、REDO ログは MySQL クラッシュ後のデータ回復を保証するクラッシュリカバリに基づいており、一方、binlog はポイントインタイムリカバリに基づいており、サーバーがデータに基づいてデータを回復できることを保証します。時点、またはデータのバックアップを作成します。

実は、MySQL には最初は REDO ログがありませんでした。当初、MySQL には InnoDB エンジンがなかったため、組み込みエンジンは MyISAM でした。 Binlog はサービス層のログであるため、すべてのエンジンで使用できます。ただし、binlog ログだけではアーカイブ機能しか提供できず、クラッシュセーフ機能を提供できないため、InnoDB エンジンは Oracle から学んだ技術、つまり REDO ログを使用してクラッシュセーフ機能を実現します。ここでは、REDO ログと binlog の特性をそれぞれ比較します。

REDO ログと binlog の特性の比較

#MySQL が update ステートメントを実行すると、これには、REDO ログと binlog ログの読み取りと書き込みが含まれます。 update ステートメントの実行プロセスは次のとおりです。

MySQL update ステートメントの実行プロセス

上の図からわかるように、MySQL は update ステートメントを実行すると、サービス層でステートメントを解析して実行します。エンジン層はデータを抽出して保存し、同時にサービス層は InnoDB にバイナリログと REDO ログを書き込みます。

それだけではなく、REDO ログの書き込みには 2 つの段階があります。1 つはバイナリログが書き込まれる前の準備状態の書き込み、もう 1 つはバイナリログが書き込まれた後のコミット状態の書き込みです。。

このような 2 段階の提出を設定したのには、当然のことながら理由があります。ここで、2 段階の送信を使用する代わりに、「単一段階」の送信、つまり、最初に REDO ログを書き込んでから binlog を書き込むか、最初に binlog を書き込んでから REDO ログを書き込むかのいずれかを採用すると仮定できます。これら 2 つの方法で送信すると、元のデータベースの状態と復元されたデータベースの状態が一致しなくなります。

最初に REDO ログを書き込み、次に binlog を書き込みます:

REDO ログを書き込んだ後、現時点ではデータにはクラッシュセーフ機能があるため、システムがクラッシュし、データがトランザクション開始前の状態に復元されます。ただし、REDO ログが完了し、バイナリログが書き込まれる前にシステムがクラッシュした場合、システムはクラッシュします。現時点では、binlog は上記の更新ステートメントを保存しないため、binlog を使用してデータベースをバックアップまたは復元すると、上記の更新ステートメントが失われます。その結果、id=2の行のデータは更新されません。

最初に REDO ログを書き込み、次に binlog を書き込む問題

最初に binlog を書き込み、次に REDO ログを書き込みます:

バイナリログの書き込み後、すべてのステートメントが保存されるため、バイナリログを通じてコピーまたは復元されたデータベースの行 id=2 のデータは a=1 に更新されます。ただし、REDO ログが書き込まれる前にシステムがクラッシュした場合、REDO ログに記録されたトランザクションは無効となり、実際のデータベースの id=2 行のデータは更新されません。

最初に binlog を書き込み、次に redo ログを作成する問題

2 段階の送信は、上記の問題を回避するために binlog を作成するためであることがわかります。 REDO ログと REDO ログに保存される情報は一貫しています。

ロールバックログ (undo ログ)

ロールバックログは、InnoDB エンジンによって提供されるログでもあり、名前が示すように、ロールバックログの機能は次のとおりです。データをロールバックします。トランザクションがデータベースを変更すると、InnoDB エンジンは REDO ログを記録するだけでなく、対応する UNDO ログも生成します。トランザクションの実行が失敗するかロールバックが呼び出され、トランザクションがロールバックされた場合、UNDO ログ内の情報はデータを復元するために使用できます。変更前の状態までスクロールします。

ただし、UNDO ログは REDO ログとは異なり、論理的なログです。 SQL ステートメントの実行に関連する情報を記録します。ロールバックが発生すると、InnoDB エンジンは、元に戻すログのレコードに基づいて、前の作業の逆を実行します。たとえば、各データ挿入操作 (insert) に対して、ロールバック中にデータ削除操作 (delete) が実行され、各データ削除操作 (delete) に対して、ロールバック中にデータ挿入操作 (insert) が実行されます。 update 操作 (update)、ロールバックする場合、データを元に戻すために逆データ更新操作 (update) が実行されます。 Undo ログには 2 つの機能があります。1 つはロールバックを提供することで、もう 1 つは MVCC を実装することです。

3. マスター/スレーブレプリケーション

マスター/スレーブレプリケーションの概念は非常に単純で、元のデータベースから同一のデータベースをコピーすることです。はマスターデータベースと呼ばれ、レプリケートされたデータベースはスレーブデータベースと呼ばれます。スレーブデータベースはデータをマスターデータベースと同期して、2 つのデータベース間のデータの一貫性を維持します。

マスター/スレーブレプリケーションの原理は、実際には bin ログを通じて実装されます。 bin log ログにはデータベース内のすべての SQL ステートメントが保存されており、bin log ログ内の SQL ステートメントをコピーして実行することで、スレーブデータベースとマスターデータベースの間で同期を実現できます。

マスター/スレーブレプリケーションプロセスを次の図に示します。マスター/スレーブレプリケーションプロセスは主に 3 つのスレッドによって実行され、送信スレッドはマスターサーバーで実行され、binlog ログをスレーブサーバーに送信するために使用されます。スレーブサーバー上では、さらに 2 つの I/O スレッドと SQL スレッドが実行されます。 I/O スレッドは、メインサーバーから送信された binlog ログの内容を読み取り、それをローカルリレーログにコピーするために使用されます。 SQL スレッドは、リレーログ内のデータ更新に関する SQL ステートメントを読み取り、それらを実行してマスターライブラリとスレーブライブラリ間のデータの一貫性を実現するために使用されます。

マスタースレーブレプリケーションの原則

#マスタースレーブレプリケーションを実装する必要がある理由は、実際には、実際のアプリケーションシナリオによって決まります。マスター/スレーブレプリケーションによってもたらされる利点は次のとおりです:

1. データのオフサイトバックアップはレプリケーションによって実現され、マスターデータベースに障害が発生した場合、データ損失を回避するためにスレーブデータベースを切り替えることができます。

2. アーキテクチャは拡張可能であり、業務量がますます増大し、I/O アクセス頻度が高すぎる場合、マルチデータベースストレージを使用することでディスク I/O アクセス頻度を減らし、パフォーマンスを向上させることができます。単一マシンの I/O、O パフォーマンス。

3. 読み取りと書き込みの分離を実現できるため、データベースはより優れた同時実行性をサポートできます。

4. 顧客のクエリの負荷をマスターサーバーとスレーブサーバーに分散して、サーバーの負荷分散を実装します。

概要

MySQL データベースは、プログラマーが習得しなければならないテクノロジーの 1 つと見なされるべきです。プロジェクトの進行中であっても、面接中であっても、MySQL は非常に重要な基礎知識です。ただし、MySQL には本当に必要なことが多すぎます。この記事を書くにあたり、色々な情報を参考にしましたが、理解できないことが多ければ多いほどわかりました。これは本当に次の格言に当てはまります:

知れば知るほど、知らないことも増えます。

この記事では、MySQL の基本トランザクションとロギングシステムの基本原理を理論的な観点から分析することに重点を置いており、説明する際には実際のコードを使用して説明することは避けるようにしています。 10,000 語近くの単語と 20 近くの手書きのイラストを含むこの記事でも、MySQL の幅広さと奥深さを完全に分析することはできません。

しかし、初心者にとって、これらの理論は MySQL の全体的な認識を与え、「リレーショナルデータベースとは何か」という質問をより明確に理解できると信じています。また、MySQL に精通している人にとっては、おそらくこの記事は、長い間失われていた根本的な理論的基礎を目覚めさせることができ、その後の面接にも役立ちます。

テクノロジーに絶対的な善悪はありません。記事に間違いがあった場合はご容赦ください。また、議論を歓迎します。独立した思考は、受動的に受け入れるよりも常に効果的です。

推奨学習: mysql ビデオチュートリアル

以上がMySQL トランザクションログを一緒に分析しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。