MySQL の基盤を強化するための課題のまとめ-mysql チュートリアル-php.cn

この記事は、mysql に関する関連知識を提供します。主に、従来の問題、インデックスクラス、プリンシパルクラス、フレームワーククラスを含む、いくつかの一般的な問題を要約し、それらを解決します。関連コンテンツ。みんなの役に立つでしょう。

MySQL の基盤を強化するための課題のまとめ

#推奨学習:

mysql ビデオチュートリアル

##一般記事

1. データベースの 3 つの主要なパラダイムについて話してください。第 1 正規形: フィールドの原子性、第 2 正規形: 一意の行と主キー列、第 3 正規形: 各列は主キー列に関連付けられます。

実際のアプリケーションでは、関連テーブルの数を減らし、クエリ効率を向上させるために、少数の冗長フィールドが使用されます。

2. 1 つのデータのみがクエリされますが、実行が非常に遅いです。一般的な理由は何ですか?

MySQL データベース自体がブロックされている (例: システムリソースまたはネットワークリソースが不足している)

SQL ステートメントがブロックされている (テーブルロック、行ロックなど)。結果として、ストレージエンジンは対応する SQL ステートメントを実行しません。
これは実際、インデックスの不適切な使用とインデックスの作成がされていないことが原因です。
テーブル内のデータの特性。インデックスが使用されています。 , ただし、テーブルの戻り数は膨大です

3. count(*)、count(0)、count(id)の実装方法の違いは何ですか？

、count(constant)、count(primary key) の形式の count 関数の場合 つまり、オプティマイザはスキャンコストが最小のインデックスを選択してクエリを実行できるため、効率が向上します。これらの実行プロセスは同じです。
の場合、オプティマイザは全テーブルスキャンを選択します。これは、クラスター化インデックスのリーフノードのみを順次スキャンできることを意味します。
指定した列を含むインデックスのみを選択してクエリを実行できます。これにより、オプティマイザによって選択されたインデックス実行コストが最小にならない場合があります。。

4. 誤ってデータを削除してしまった場合はどうすればよいですか?

1) データ量が比較的大きい場合は、物理バックアップ xtrabackup を使用します。データベースの完全バックアップを定期的に実行します。また、増分バックアップを実行することもできます。

2) データ量が少ない場合は、mysqldump または mysqldumper を使用して、binlog を使用してデータを回復するか、マスター/スレーブ方式を設定してデータを回復します。 #

DML 誤操作ステートメント: フラッシュバックを使用して、最初に binlog イベントを解析し、次にそれを元に戻すことができます。
DDL ステートメントの誤操作: データは完全バックアップとバイナリログアプリケーションを通じてのみ復元できます。データの量が比較的多くなると、回復時間が特に長くなります。
rm 削除: コンピュータルーム全体、できれば都市全体でバックアップを使用します。

5. ドロップ、トランケート、削除の違い

DELETE ステートメントは、テーブルから一度に 1 行ずつ削除します。同時に、行の削除操作は、ロールバック操作のトランザクションレコードとしてログに保存されます。
TRUNCATE TABLE は、テーブルからすべてのデータを一度に削除し、個々の削除操作レコードをログに記録しません。削除された行は復元できません。また、削除処理中にテーブルに関連する削除トリガーが起動されず、実行速度が速くなります。
drop ステートメントは、テーブルによって占められていたすべてのスペースを解放します。

6. MySQL の大きなテーブルクエリがメモリをバーストしないのはなぜですか?

MySQL は「読み取り中に送信」です。つまり、クライアントの受信が遅い場合、このトランザクションの実行時間が短縮されるため、MySQL サーバーは結果を送信できません。 . 長くする。
サーバーは完全な結果セットを保存する必要はありません。データの取得および送信のプロセスはすべて next_buffer を通じて操作されます。
メモリデータページはバッファプール (BP) で管理されます。
InnoDB は、リンクリストを使用して実装された、改良された LRU アルゴリズムを使用してバッファプールを管理します。 InnoDB の実装では、コールドデータが大規模なバッチでロードされたときにホットデータが流されないように、LRU リンクリスト全体が 5:3 の比率に従って若いエリアと古いエリアに分割されます。

7. 深いページング (非常に大きなページング) に対処する方法は?

ID を使用して最適化する: まず、最後のページングの最大 ID を見つけます。ページングを実行し、次に select * from user where id>1000000 limit 100 と同様に、id のインデックスを使用して Query を使用します。
カバリングインデックスの最適化を使用する: MySQL クエリがインデックスに完全にヒットすると、それはカバリングインデックスと呼ばれます。クエリはインデックス上で検索するだけでよく、その後は戻ることなく直接戻ることができるため、非常に高速です。テーブルデータを取得するしたがって、最初にインデックスの ID を見つけて、次にその ID に基づいてデータを取得できます。
ビジネスが許可する場合はページ数を制限してください

8. 日々の開発で SQL をどのように最適化していますか?

適切なインデックスの追加: クエリ条件として使用されるフィールドのインデックスを作成し、並べ替えます。複数のクエリフィールドを考慮して結合インデックスを確立し、結合インデックスの順序に注意します。最も一般的に使用されるフィールド制限条件として使用される列は、降順で左端に配置されます。インデックスは多すぎてはならず、通常は 5 以内です。
テーブル構造の最適化: 文字列型よりも数値フィールドの方が優れています。通常、データ型が小さいほど優れています。NOT NULL を使用するようにしてください。
クエリステートメントの最適化: SQL 実行プランを分析し、インデックスにヒットするかどうかを確認します。 , など、SQL が非常に複雑な場合は、SQL 構造を最適化します。テーブルのデータ量が多すぎる場合は、サブテーブルを検討します。

9. 同時実行との違いは何ですか? MySQL での接続と同時クエリは?

show processlist を実行した結果、数千の接続が表示されました。これは同時接続を指します。
「現在実行中」ステートメントは同時クエリです。
同時接続の数はメモリに影響します。
同時クエリが多すぎると、CPU に悪影響を及ぼします。マシンの CPU コアの数は限られており、すべてのスレッドが殺到すると、コンテキスト切り替えのコストが高くなりすぎます。
スレッドがロック待機に入った後は、同時スレッド数が 1 つ減るため、行ロックまたはギャップロックを待機しているスレッドはカウント範囲に含まれないことに注意してください。つまり、ロックを待機しているスレッドが CPU を消費しないため、システム全体のロックが防止されます。

10. フィールド値を元の値に更新するとき、MySQL は内部的にどのように動作しますか?

同じデータを使用する場合、更新は行われません。
ただし、バイナリログ形式が異なれば、ログ処理方法も異なります。
- 1) 行モードに基づく場合、サーバー層は更新されるレコードと一致し、新しい値が一致していることを確認します。古い値は更新されずに直接返され、バイナリログは記録されません。
- 2) ステートメントまたは混合形式に基づく場合、MySQL は更新ステートメントを実行し、更新ステートメントを binlog に記録します。

#11. 日時とタイムスタンプの違いは何ですか?

日時の日付範囲は 1001 ～ 9999、タイムスタンプの時間範囲は 1970 ～ 2038 です。
日時の保存時間はタイムゾーンとは関係ありません。タイムスタンプの保存時間はタイムゾーンに関係なく、表示される値もタイムゾーンによって異なります
datetime のデフォルト値は null; タイムスタンプフィールドのデフォルト値 null ではありません、デフォルト値は現在の時刻 (current_timestamp)

12. トランザクションの分離レベルは何ですか?

「Read Committed」はダーティリードの発生を回避できます
「Repeatable Read」はダーティリードと Non-Repeatable Read を回避できます
「Serializable」はダーティリード、Non-Repeatable Read、ファントムリードを回避できます発生状況
Mysql のデフォルトのトランザクション分離レベルは"Repeatable Read"

13. MySQL には 2 つの kill コマンドがあります

kill接続スレッドID、接続をデフォルトにすることができ、スレッドを切断することを示します

Index

1.インデックスカテゴリですか？

リーフノードの内容に応じて、インデックスタイプは主キーインデックスと非主キーインデックスに分かれます。
主キーインデックスのリーフノードには、データ行全体が格納されます。 InnoDB では、主キーインデックスはクラスター化インデックスとも呼ばれます。
非主キーインデックスのリーフノードの内容は、主キーの値です。 InnoDB では、主キー以外のインデックスはセカンダリインデックスとも呼ばれます。

2. クラスター化インデックスと非クラスター化インデックスの違いは何ですか?

クラスター化インデックス: クラスター化インデックスは、主キーを使用して作成されるインデックスであり、テーブル内のデータをリーフノードに格納します。
非クラスター化インデックス: 非主キーによって作成されたインデックスは、主キーとインデックス列をリーフノードに保存します。 -クラスター化インデックスでデータをクエリし、リーフの主キーを取得して、検索したいデータを見つけます。 (主キーを取得して検索するプロセスは、テーブルリターンと呼ばれます)。
カバーされたインデックス: クエリ対象の列がたまたまインデックスに対応する列であると仮定し、インデックスに戻る必要はありません。検索するテーブルの場合、このインデックス列はカバーインデックスと呼ばれます。

#3. InnoDB が B ツリー、ハッシュ、バイナリツリー、赤黒ツリーではなく B ツリーを設計するのはなぜですか?

ハッシュインデックスは、単一データ行の追加、削除、変更、クエリを O(1) の速度で処理できますが、範囲クエリや並べ替えに直面すると、フルテーブルスキャンの結果。
B ツリーは、非リーフノードにデータを保存できます。すべてのノードにターゲットデータが含まれる可能性があるため、条件を満たすデータ行を見つけるには、常にルートノードからサブツリーを下方向にたどる必要があります。この機能により、大量のランダム I/O が発生し、パフォーマンスの低下を引き起こします。
B ツリーのすべてのデータ行はリーフノードに格納されており、これらのリーフノードは「ポインタ」を介して順番に接続できます。以下に示すように B ツリー内のデータをトラバースすると、直接アクセスできます。ノード間をジャンプすると、ディスク I/O 時間を大幅に節約できます。
二分木: 木の高さが不均一で自己平衡が取れず、検索効率はデータ (木の高さ) に関係し、IO コストが高くなります。
赤黒ツリー: データ量が増えるとツリーの高さが増し、IO コストが高くなります。

4. クラスター化インデックスと非クラスター化インデックスについて話しましょう。

InnoDB では、データの行全体を格納するインデックス B ツリーのリーフノードは、データストレージとインデックスをまとめた主キーインデックス (クラスター化インデックスとも呼ばれます) です。インデックスが見つかると、データが見つかります。
インデックス B ツリーのリーフノードは主キーの値を格納し、非主キーインデックス (非クラスター化インデックスやセカンダリインデックスとも呼ばれます) です。
最初のインデックスは通常シーケンシャル IO で、テーブルに戻る操作はランダム IO です。テーブルに戻る必要がある回数が増えるほど、つまりランダム IO が必要な回数が増えるほど、テーブル全体のスキャンを使用する傾向が高くなります。

5. 非クラスター化インデックスは確実にテーブルクエリを返しますか?

これには、クエリステートメントで必要なすべてのフィールドがインデックスにヒットするかどうかが含まれます。すべてのフィールドがインデックスにヒットした場合、クエリを実行する必要はありません。テーブル。インデックスにはクエリが必要なすべてのフィールドの値が含まれ (カバーされ)、「カバーインデックス」と呼ばれます。

6. MySQL の一番左のプレフィックスの原則について話しますか?

The leftmost prefix priority is leftmost priority. 複数列のインデックスを作成する場合、ビジネスニーズに応じて、where 句で最も頻繁に使用される列が最も左側に配置されます。
MySQL は、範囲クエリ (>、<、between、like) に遭遇するまで右へのマッチングを続け、その後、a = 1、b = 2、c > 3 などのマッチングを停止します。 and d = 4 if (a, b, c, d)の順にインデックスを作成します dのインデックスは使用しません (a, b, d, c)のインデックスを作成すれば使用できます. a、b、dの順序は任意です。
= と in は、a = 1、b = 2、c = 3 のように順不同になる可能性があります。(a, b, c) インデックスは任意の順序で作成できます。MySQL のクエリオプティマイザーが役立ちます。インデックスの最適化、識別の形式。

7. インデックスプッシュダウンとは何ですか?

左端のプレフィックスの原則が満たされている場合、左端のプレフィックスを使用してインデックス内のレコードを検索できます。
MySQL 5.6 より前では、ID から開始して 1 つずつテーブルを返すことしかできませんでした。主キーインデックスでデータ行を検索し、フィールド値を比較します。
MySQL 5.6 で導入されたインデックスプッシュダウン最適化 (インデックス条件プッシュダウン) は、インデックストラバーサルプロセス中にインデックスに含まれるフィールドを最初に判断し、条件を満たさないレコードを直接フィルタリングして除外し、テーブルのリターンを削減します。頻度。

8. Innodb が主キーとして自動インクリメント ID を使用するのはなぜですか?

テーブルで自動増加主キーが使用されている場合、新しいレコードが挿入されるたびに、レコードは現在のインデックスノードの後続の位置に順番に追加されます。ページがいっぱいの場合は、自動的に新しいページが開きます。自動増加しない主キー (ID 番号や学生番号など) が使用される場合、毎回挿入される主キーの値はほぼランダムであるため、新しいレコードはそれぞれ、レコードの中央のどこかに挿入する必要があります。既存のインデックスページが頻繁に使用されていました。移動操作やページング操作により大量の断片化が発生し、その結果インデックス構造が十分にコンパクトではなくなりました。その後、テーブルを再構築し、埋められたページを最適化するために OPTIMIZE TABLE (テーブルの最適化) を使用する必要がありました。

9. トランザクション ACID 機能はどのように実装されますか?

「アトミシティ」: アンドゥログを使用して実装されています。トランザクション実行中にエラーが発生した場合、またはユーザーがロールバックを実行した場合、システムはトランザクション開始のステータスをアンドゥログを通じて返します。
「永続性」: これを実現するには、REDO ログを使用します。REDO ログが永続化されている限り、システムがクラッシュした場合でも、REDO ログを通じてデータを回復できます。
「分離」: トランザクションはロックと MVCC を通じて互いに分離されます。
「一貫性」: 一貫性は、同時状況でのロールバック、リカバリ、および分離によって実現されます。

10. B ツリーインデックスの実装方法における MyISAM と InnoDB の違いは何ですか?

InnoDB ストレージエンジン: B ツリーインデックスのリーフノードはデータ自体を保存します;
MyISAM ストレージエンジン: B ツリーインデックスの葉ノードがデータを保存する物理アドレス;
InnoDB は、データファイル自体がインデックスファイルです。MyISAM と比較して、インデックスファイルとデータファイルが分離されています。テーブルデータファイル自体は B Tree によって編成されたインデックス構造であり、ノードデータフィールドは、ツリーが保存されます。完全なデータレコードが取得されます。このインデックスのキーはデータテーブルの主キーです。したがって、InnoDB テーブルデータファイル自体が主インデックスです。これは「クラスター化インデックス」またはクラスター化インデックスと呼ばれます補助インデックスデータフィールドには、アドレスの代わりに、対応するレコードの主キーの値が格納されます。これも MyISAM とは異なります。

11. インデックスのカテゴリは何ですか?

リーフノードの内容に応じて、インデックスタイプは主キーインデックスと非主キーインデックスに分かれます。
主キーインデックスのリーフノードには、データ行全体が格納されます。 InnoDB では、主キーインデックスはクラスター化インデックスとも呼ばれます。
非主キーインデックスのリーフノードの内容は、主キーの値です。 InnoDB では、主キー以外のインデックスはセカンダリインデックスとも呼ばれます。

12. インデックスの失敗はどのようなシナリオで発生しますか?

背景: B ツリーによって提供される高速測位機能は、同じレイヤー上の兄弟ノードの順序性によってもたらされるため、この順序性が破壊されると、B ツリーは失敗する可能性が高くなります。具体的には、次のような状況があります:

# インデックスで左または左のあいまい一致を使用します。つまり、%xx または %xx% のようにします。これらのメソッドは両方とも、インデックスが失敗する原因となります。その理由は、クエリ結果が「Chen Lin、Zhang Lin、Zhou Lin」などになる可能性があるため、どのインデックス値と比較を開始すればよいかわからないため、フルテーブルスキャンを通じてのみクエリを実行できるためです。
インデックスに関数を使用する/インデックスに式計算を使用する: インデックスは、関数によって計算された値ではなく、インデックスフィールドの元の値を保存するため、索引。。
インデックスの暗黙的な型変換: 新しい関数を使用するのと同等 WHERE 句で
OR: 条件を満たす限り 2 を意味しますしたがって、条件付き列が 1 つだけインデックス列である場合は意味がありません。条件付き列がインデックス列でない限り、テーブル全体のスキャンが実行されます。

提案

1. データベースとテーブルに分割されていないシステムがあるが、動的に分割に切り替えるように設計するにはどうすればよいかデータベースとテーブル?

拡張の停止 (非推奨)
二重書き込み移行計画: 拡張されたテーブル構造計画を設計し、単一データベースとサブデータベースに二重書き込みを実装します。 , 観察 1週間問題がなければ、単一データベースの読み取りトラフィックをオフにしてしばらく観察し、安定し続けたら、単一データベースの書き込みトラフィックをオフにして、サブデータベースにスムーズに切り替えますそしてサブテーブル。

2. 容量を動的に拡張および削減できるサブデータベースとテーブルのスキームを設計するにはどうすればよいですか?

原則

1. MySQL ステートメントを実行する手順は何ですか?

サーバー層が SQL を順番に実行する手順は次のとおりです:
クライアントリクエスト -> コネクタ (ユーザー ID の確認、権限の付与) -> キャッシュのクエリ (キャッシュが存在する場合は直接返す) , 存在しない場合は以降の操作が行われます） -> Analyzer（SQLの字句解析や構文解析操作） -> Optimizer（主にSQLの最適化を実行するための最適な実行計画方法を選択します） -> Executor（実行）このエンジンが提供するインターフェイスを使用する前に、ユーザーに実行権限があるかどうかが最初にチェックされます) -> エンジン層に移動してデータの戻り値を取得します (クエリキャッシュがオンになっている場合、クエリ結果はキャッシュされます)。

2. ソートによる順序付けの内部原理は何ですか?

MySQL はソートのために各スレッドにメモリ (sort_buffer) を割り当てます。メモリサイズは sort_buffer_size です。
ソート中のデータ量がsort_buffer_size未満の場合、ソートはメモリ内で完了します。
並べ替えられたデータの量が多く、メモリに格納できない場合は、ディスク上の一時ファイルを使用して並べ替えが行われます (外部並べ替えとも呼ばれます)。
外部ソートを使用する場合、MySQL はソートされたデータを保存するためにそれをいくつかの個別の一時ファイルに分割し、これらのファイルを 1 つの大きなファイルにマージします。

3. MVCC 実装原則?

MVCC (マルチバージョン同時実行制御) は、同じデータの複数のバージョンを保持することで同時実行制御を実現する方法です。クエリを実行するときは、読み取りビューとバージョンチェーンを通じて、対応するバージョンのデータを検索します。
機能: 同時実行パフォーマンスを向上させます。同時実行性の高いシナリオの場合、MVCC は行レベルのロックよりも安価です。
MVCC の実装は、テーブルの 3 つの非表示フィールドを通じて実装されるバージョンチェーンに依存します。
- 1) DB_TRX_ID: 現在のトランザクション ID。トランザクションの時系列はトランザクション ID のサイズによって判断されます。
- 2) DB_ROLL_PRT: ロールバックポインタは、現在の行レコードの前のバージョンを指します。このポインタを通じて、データの複数のバージョンが結合され、UNDO ログバージョンチェーンが形成されます。
- 3) DB_ROLL_ID: 主キーデータテーブルに主キーがない場合、InnoDB は自動的に主キーを生成します。

#4. 変更バッファとは何ですか?またその機能は何ですか?

5. MySQL はどのようにしてデータが失われていないことを保証しますか?

redolog と binlog が永続ディスクを保証している限り、データは保証されます。 MySQL が異常に再起動した後、バイナリログ書き込みメカニズムを復元します。
redolog は、システム例外の後に失われたデータを確実にやり直すことができるようにし、binlog はデータをアーカイブして、失われたデータを確実に復元できるようにします。
トランザクション実行前に redolog を書き込みます。トランザクション実行中、ログは最初に binlog キャッシュに書き込まれます。トランザクションが送信されると、binlog キャッシュは binlog ファイルに書き込まれます。

#6. テーブルを削除した後もテーブルファイルのサイズが変わらないのはなぜですか?

データ項目が削除された後、InnoDB はページ A をマークし、再利用可能としてマークされます。
テーブルのデータ全体を削除する delete コマンドはどうですか?その結果、すべてのデータページが再利用可能としてマークされます。ただし、ディスク上ではファイルは小さくなりません。
多数の追加、削除、変更が行われたテーブルには穴がある可能性があります。これらの穴もスペースを占めるため、これらの穴を削除できれば、テーブルのスペースを縮小するという目的を達成できます。
テーブルを再構築することで、この目的を達成できます。 alter table A Engine=InnoDB コマンドを使用してテーブルを再構築できます。

7. 3 つのバイナリ形式の比較

# 行形式のバイナリログには、操作行の主キー ID と真の値が記録されます。したがって、一次運転データと二次運転データに不整合が生じることはありません。
ステートメント: 記録されたソース SQL ステートメント
mixed: 最初の 2 つは混合されていますが、混合形式のファイルが必要なのはなぜですか? ステートメント形式の一部のバイナリログは、プライマリとステートメントの間で不整合を引き起こす可能性があるためです。セカンダリサーバーなので、行形式を使用する必要があります。ただし、行形式の欠点は、多くのスペースを必要とすることです。 MySQL は妥協をとりました。この SQL ステートメントがプライマリサーバーとセカンダリサーバー間で不整合を引き起こす可能性があるかどうかを MySQL 自体が判断します。可能であれば行形式を使用し、そうでない場合はステートメント形式を使用します。

8. MySQL ロックルール

原則 1: ロックの基本単位はネクストキーロックであり、ネクストキーロックは前開いてから閉じる間隔。
原則 2: 検索プロセス中にアクセスされたオブジェクトのみがロックされます
最適化 1: インデックスに対する同等のクエリ。一意のインデックスをロックする場合、ネクストキーロックは行ロックに縮退します。
# #a バグ: 一意のインデックスに対する範囲クエリは、条件を満たさない最初の値にアクセスします。

9. ダーティリード、ノンリピータブルリード、ファントムリードとは何ですか?

「ダーティリード」: ダーティリードとは、コミットされていないデータを他のトランザクションから読み取ることを指します。コミットされていないということは、データがロールバックされる可能性があり、最終的にデータが保存されない可能性があることを意味します。データベース内、つまり存在しないデータ。最終的には存在しない可能性のあるデータの読み取りは、ダーティリードと呼ばれます。

「反復不可能な読み取り」: 反復不可能な読み取りとは、トランザクション内で、最初に読み取られたデータが、トランザクションの終了前の任意の時点で読み取られた同じデータのバッチと矛盾する状況を指します。。
「ファントム読み取り」: ファントム読み取りは、2 つの読み取りによって得られた結果セットが異なることを意味するものではありません。ファントム読み取りの焦点は、特定の選択操作によって得られた結果のデータ状態がその後のビジネスをサポートできないことです。オペレーション。。具体的には、あるレコードが存在するかどうかを選択し、存在しない場合は、レコードを挿入する準備をしますが、挿入を実行すると、すでにレコードが存在していることがわかり、挿入できません。このとき、ファントムリードが発生します。が発生します。

10. MySQL にはどのような種類のロックがありますか? 上記のようなロックは同時実行効率の妨げになりませんか?

ロックの観点からカテゴリには、共有ロックと排他ロックがあります。

1) 共有ロック: 読み取りロックとも呼ばれます。ユーザーがデータを読みたいときに、データに共有ロックが追加されます。複数の共有ロックを同時に追加できます。
- 2) 排他ロック: 書き込みロックとも呼ばれます。ユーザーがデータを書き込みたいとき、データに排他ロックを追加します。追加できる排他ロックは 1 つだけであり、他の排他ロックや共有ロックは反発します。お互い。
ロックの粒度は特定のストレージエンジンによって異なります。InnoDB は行レベルのロック、ページレベルのロック、およびテーブルレベルのロックを実装します。
ロックオーバーヘッドは大から小に増加し、同時実行機能も大から小に増加します。

1. MySQL マスター/スレーブレプリケーションの原理は何ですか?

マスターの更新イベント (更新、挿入、削除) は、順番に

に書き込まれます。スレーブがマスターに接続されると、マスターマシンはスレーブの binlog dump スレッドを開き、このスレッドが bin-log ログを読み取ります。スレーブがマスターに接続された後、スレーブライブラリには
があり、binlog ダンプスレッドを要求して bin-log ログを読み取り、それをスレーブに書き込みます。ライブラリの リレーログログ内。スレーブには
もあり、リレーログのログ内容がリアルタイムで更新されているかどうかを監視し、ファイル内の SQL ステートメントを解析してスレーブデータベースで実行します。

2. Mysql のマスター/スレーブレプリケーション同期方法とは何ですか?

Mysql マスター/スレーブ同期デフォルトは非同期レプリケーションです。つまり、上記の 3 つのステップのうち、最初のステップのみが同期的です (つまり、Mater が bin ログログを書き込みます)。つまり、マスターライブラリは、binlog ログを書き込んだ後、binlog を待たずにクライアントに正常に戻ることができます。スレーブライブラリに転送されるログ。
同期レプリケーションの場合、マスターホストがスレーブホストにイベントを送信した後、すべてのスレーブノード (複数のスレーブがある場合) がイベントを返すまで待機がトリガーされます。データ複製が成功したという情報をマスターに送信します。
準同期レプリケーションの場合、マスターホストがスレーブホストにイベントを送信した後、いずれかのスレーブノードが送信されるまで 待機がトリガーされます。 (if (複数のスレーブがある場合) は、成功したデータ複製に関する情報をマスターに返します。

3. Mysql のマスター/スレーブ同期の遅延の原因は何ですか?最適化するにはどうすればよいですか?

4. Mysql のマスターとスレーブの同期遅延の原因は何ですか? 最適化するにはどうすればよいですか?

大規模なトランザクション: 大規模なトランザクションを小さなトランザクションに分割し、バッチでデータを更新します
スレーブの数を 5 つ以下に減らし、単一トランザクションのサイズを縮小します。
Mysql 5.7 以降では、マルチスレッドレプリケーションと MGR レプリケーションアーキテクチャを使用できます。
ディスク、RAID カード、およびスケジューリング戦略に問題がある場合、単一の IO 遅延が発生する可能性があります。 iostat コマンドを使用して DB データディスクの IO ステータスを確認し、さらに判断します
ロックの問題については、プロセスリストを確認し、ロックとトランザクションに関連するテーブルを確認できますinformation_schema の下にあります。

6. bin ログ/redo ログ/undo ログとは何ですか?

bin ログは、Mysql データベースレベルのファイルです。Mysql データベースを変更するすべての操作が記録されます。select ステートメントと show ステートメントは記録されません。
更新されるデータは、REDO ログに記録されます。たとえば、データが正常に送信された場合、そのデータはすぐにはディスクに同期されません。代わりに、REDO ログに記録されます。最初にログを記録し、適切なタイミングでディスクをフラッシュするのを待ちます。
undo ログはデータの呼び出し操作に使用され、レコードが変更される前の内容を保持します。トランザクションのロールバックはアンドゥログを通じて実現でき、MVCC はアンドゥログに基づいてデータの特定のバージョンまでトレースバックすることで実装できます。

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

以上がMySQL の基盤を強化するための課題のまとめの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。