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

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

#推奨学習:

mysql ビデオ チュートリアル

##一般記事

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

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

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

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

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

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

count(*)
• 、count(constant)、count(primary key) の形式の count 関数の場合 つまり、オプティマイザはスキャン コストが最小のインデックスを選択してクエリを実行できるため、効率が向上します。これらの実行プロセスは同じです。
count (非インデックス列)
• の場合、オプティマイザは全テーブル スキャンを選択します。これは、クラスター化インデックスのリーフ ノードのみを順次スキャンできることを意味します。
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 です。
• 日時の保存時間はタイム ゾーンとは関係ありません。タイムスタンプの保存時間はタイムゾーンに関係なく、表示される値もタイムゾーンによって異なります
#日時の保存スペースは8バイト、タイムスタンプの保存スペースは4バイト
• datetime のデフォルト値は null; タイムスタンプ フィールドのデフォルト値 null ではありません、デフォルト値は現在の時刻 (current_timestamp)

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

「Read Uncommitted」は最低レベルであり、いかなる状況でも保証されません
• 「Read Committed」はダーティ リードの発生を回避できます
• 「Repeatable Read」はダーティ リードと Non-Repeatable Read を回避できます
• 「Serializable」はダーティ リード、Non-Repeatable Read、ファントム リードを回避できます 発生状況
• Mysql のデフォルトのトランザクション分離レベルは"Repeatable Read"

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

kill クエリ スレッド ID で実行されているステートメントを終了することを示します。このスレッド
• 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: インデックスに対する同等のクエリ。一意のインデックスをロックする場合、ネクスト キー ロックは行ロックに縮退します。
#最適化 2: 右側のインデックスの等しい値クエリをトラバースし、最後の値が等価条件を満たさない場合、次のキー ロックはギャップ ロックに縮退します
• # #a バグ: 一意のインデックスに対する範囲クエリは、条件を満たさない最初の値にアクセスします。

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

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

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

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

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

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

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

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

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

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

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

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

マスター ノードが大規模なトランザクションを実行すると、マスター/スレーブ遅延に大きな影響を及ぼします
ネットワーク遅延、大規模なログ、多すぎるスレーブ
マスターではマルチスレッド書き込み、スレーブ ノードでは単一スレッドの同期のみ
マシンのパフォーマンススレーブ ノードが「不良マシン」を使用しているかどうかの問題。
ロック競合の問題により、スレーブの SQL スレッドの実行速度が遅くなる可能性もあります。

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 サイトの他の関連記事を参照してください。