Mysqlデータベースの技術知識照合

MySQL ナレッジ ポイント ディレクトリ

• 焦点: アーキテクチャ、エンジン、インデックス、ロック メカニズム、トランザクション メカニズム、ログ メカニズム、クラスター、チューニング

3.MySQLインデックス

• インデックスの概念
  • カバリングインデックス: 条件列と結果列の両方がインデックス内にあります。
  • インデックス プッシュダウン: クエリは最初に条件列をフィルターし、次にテーブルに戻ってデータを確認します。
  • 左端のプレフィックス一致: クエリ条件は左端からインデックス列と一致します。
  • 表に戻る: インデックス クエリの後、満足できない場合は、すべてのデータを ID でクエリする必要があります。
• インデックス失敗の理由
  • or,!=,not in，like等
• インデックス作成の原則
  • 左端のプレフィックスの原則
  • インデックスを作成するには、より多くを読み取り、より少ない書き込みを行います。より多くの書き込みには適していません。
  • インデックスを破壊するクエリを避ける
  • 元のインデックスの作成を優先し、新しいインデックスの作成を回避します。
  • 識別性の低い列、外部キーにはインデックスが付けられません
  • 使用されなくなった、またはめったに使用されないインデックスを削除します。

4.mysqlのロック機構

• ロック機構：楽観ロック（MVCC機構）、悲観ロック
• ロックの粒度: グローバル ロック、テーブル ロック、行ロック、リーフ ロック、ギャップ ロック
• 互換性：共有ロック（Sロック）、排他ロック（Xロック）
• ロックモード：レコードロック（行ロック）、ギャップロック、インテントロック（読み取り、書き込み、挿入インテントロックに分割）、ネクストキーロック、自動インクリメント
• デッドロックの解決策
  • 相互排他条件、リクエストアンドホールド条件、ループ待機条件、プリエンプションなし条件
  • 解決策: ループを切断する
  • デッドロックとインデックスは切り離せないものです。インデックスの問題を解決するには、インデックスを合理的に最適化する必要があります。
  • 同じトランザクション内で、デッドロックの可能性を減らすために、必要なすべてのリソースを一度にロックするようにしてください。

MySQL のマスター/スレーブ レプリケーション、読み取り/書き込み分離

• mysqlのマスターとスレーブの同期遅延

  • 理由: メイン データベースが高い同時書き込み操作を実行している場合、特定の SQL の長い実行時間、または SQL ロック テーブルによるメイン データベース内の SQL のバックログが原因で、すぐにスレーブ データベースに同期できません。
  • シナリオ: 同時実行性が高いシナリオでは、データベース フィールドを変更したり、長いトランザクションが発生したりすると、マスター/スレーブの遅延が発生します。
  • 解決：
    • ライブラリからの読み取り操作: sync_binlog=0、SQL 実行効率の送信、またはより良い機器の使用
    • ハードウェアに関して: (1) スレーブ ライブラリとしてより良い機器を使用する、(2) スレーブ ライブラリ内のマシンの数を増やす、(3) 特定のスレーブ ライブラリをバックアップとして使用する、クエリ操作を処理しない
  • マスターとスレーブの遅延の判断: show slide status による、Seconds_Behind_Master パラメータの判断による

• マスター/スレーブレプリケーションの遅延問題

• mysqlの読み取りと書き込みの分離

  • アプリケーション層は、スレーブ ライブラリと同期して、メイン ライブラリの DML ステートメントの操作を制御します。
  • アプリケーション層は、スレーブ ライブラリ内の SQL ステートメントの操作を制御します。
  • アプリケーション層が読み取りおよび書き込みイベントを操作するとき、一貫性を確保するためにメイン ライブラリの強制的な読み取りを要求できます。

• mysqlマスタースレーブ遅延

  • 主にビジネスニーズに基づいて、
  • 強い一貫性が必要です。すべての読み取りと書き込みはメイン ライブラリ内で行われます。
  • 弱い一貫性: 一般的な読み取りはスレーブ ライブラリで行われ、トランザクションの読み取りと書き込みはすべてメイン ライブラリで行われます。
  • 最終的な整合性: メイン ライブラリに書き込み、ライブラリから読み取る

MySQLサブデータベースサブテーブル

• サブデータベースおよびサブテーブルのミドルウェア ソリューション
  • Dangdang-shardingjdbc、Ali-mycat、Ali-tddl、Ali-cobar、58.com-Oceanus、Ali-OneProxy、Google-vites
• サブデータベースサブテーブルの問題
  • ビジネス上の問題
    • 方法 1: 分散トランザクションを使用します。シンプルで効果的ですが、パフォーマンスにコストがかかります。
    • 方法 2: 複数のデータベースにまたがる分散トランザクションを単一データベース内の複数の小さなミスに分割し、プログラムを通じて小さなトランザクションを制御します。これにより、パフォーマンスには利点がありますが、結合は破壊されます。
  • クロスノード結合の問題
    • 方法: 単一テーブルの統合操作、プログラムによって制御
  • クロスノード数、orderby、groupby
    • 方法: join と同様、各ノードで実行してからマージします。
  • IDの問題
    • Redis の自己インクリメント ID
    • スノーフレークアルゴリズムによるID生成
    • データベースは順序を維持します
  • シャード間でのページネーションの問題のソート
    • データベース間のクエリ ページングを回避してください。回避できない場合は、メモリ ページングを使用してください。
  • データ移行、容量計画、および容量拡張の問題
    • 事前に計画を立てる

マスタースレーブ遅延問題

• マスターとスレーブの同期手順:
  • メインライブラリが更新され、bin_log に書き込まれます。
  • ライブラリからメイン ライブラリへの接続を開始します。
  • メイン ライブラリはバイナリ ログ ダンプ スレッドを作成し、バイナリ ログの内容をスレーブ ライブラリに送信します。
  • IO スレッドを通じて、binlog の内容を読み取り、リレー ログに書き込みます。
  • スレーブ ライブラリは、リレー ログの内容を読み取って実行する SQL スレッドも作成します。
• 理由：
  • ライブラリによるマシンのパフォーマンスの低下
  • 図書館からのアクセスに対するプレッシャーが大きい
  • 大事業の遂行
  • メインライブラリのDDL（変更、ドロップ、作成）
  • ロックの競合
  • ライブラリからのレプリケーション機能
• 解決：
  • メインサービスが更新を担当し、セキュリティが高いのでパラメータを設定し、
    • 例: sync_binlog=1
    • 例: innodb_flush_log_at_trx_commit=1
  • より良いデバイスをスレーブ ライブラリとして使用するか、より多くのスレーブ ライブラリを設定します
  • 特定のスレーブ ライブラリはクエリを提供しませんが、特に bin_log 同期をスレーブ ライブラリに提供します。
  • マルチスレッドの大規模トランザクションの同時実行の可能性を減らし、ビジネス ロジックを最適化します。
  • SQL を最適化し、遅い SQL を回避し、バッチ操作を減らすには、update-sleep の形式でスクリプトを作成することをお勧めします。
  • 最短のリンクを使用するようにしてください。つまり、マスター ライブラリとスレーブ ライブラリ サーバー間の距離をできるだけ短くして、ポート帯域幅を増やし、バイナリログ送信のネットワーク遅延を減らす必要があります。
  • リアルタイム パフォーマンスを必要とするビジネス読み取りは強制的にマスター ライブラリに送られ、スレーブ ライブラリは災害復旧とバックアップにのみ使用されます。

BufferPool バッファプールについて

• MySQL データはディスクに保存され、SQL のニーズに応じてインデックス作成やその他の方法を通じてディスクからバッファ プールにフラッシュされます。
• mysql の SQL 操作はディスク上で操作されるようになり、トランザクションの完了後にディスクは Bin_log を通じてディスクにフラッシュされます。

データテーブルの設計

データテーブルタイプ

• 最初のカテゴリ: フロー テーブル、ログ テーブル、
• 2 番目のタイプ: 状態タイプ、コア データの記録
• 3 番目のカテゴリ: 構成テーブル、データが少ない、最適化する必要がない

インタビュー: MySQL チューニングについて語る

1. チューニングの手順

• 1. 位置決めの問題:
• 2. 問題を分析する
• 3. 問題を解決する
• 4. 検証結果

ステップ 1: 問題の特定

• サービス監視を通じて、サービスが停止またはタイムアウトした時間を見つけ、インターフェイスを分析します
• インターフェースを通じてコードを特定し、さらに実行されたSQLを特定し、実行時間を確認し、シーンを確認します。

ステップ 2: 問題を分析する

• データベース監視を通じて、問題が発生したときにDBクラスターデータのCPU、メモリ、IOディスク、ネットワーク、スレッド数などのパラメータを確認します。
• 現場のパラメータを分析し、SQLと組み合わせることで、以下のような問題点を特定します。
  • CPUが高すぎる、SQLでの操作があるか、スループットが高すぎるかなどを確認してください。
  • メモリが多すぎるか、SQL がインデックスに役立つかどうか、テーブルが頻繁に返されるかどうか
  • IO ディスクが大きすぎます。大規模なテーブル結合などの問題があるかどうか
  • ネットワークの遅延が大きいですが、クラウドサービスのネットワークに問題がありますか?
  • スレッドの問題、長いトランザクションがロックの問題を引き起こすかどうか

ステップ 3: 問題を解決する

• システム負荷が高すぎる、DBを拡張する、サブデータベースとサブテーブルを使用する、読み取りと書き込みを分離するなど、アプリケーション層のキャッシュを増やすなど。
• SQL の理由により、通常は Explain 分析を通じて、SQL の最適化、インデックスの追加、カバーインデックスの使用、冗長インデックスの削除などを実行します。
• 長いトランザクションを最適化し、トランザクションプロセスを短縮します
• 分散キャッシュやDAOキャッシュの追加など、アプリケーションを最適化します。

ステップ 4: 結果を確認する

• リクエストの応答時間の短縮、システム負荷の軽減など、期待値を設定します。
• 最初に耐圧テスト環境で更新し、次に耐圧テスト検証に合格する
• 耐圧テストで問題がなければ本番環境に導入

Mysqlのチューニング

Mysql の基礎となる知識ポイント

ログの種類と機能

• general_log 一般ログ
• error_log エラーログ
• low_query_log スロークエリログ
• lay_log リレー ログ – データ同期、障害回復機能
  • リレー ログ ログ ファイルの形式は bin ログ ログ ファイルと同じです
  • リレー ログは転送の役割を果たします。スレーブはまずマスター データベースからバイナリ ログ データを読み取り、それをローカルでスレーブ ライブラリに書き込み、次に SQL スレッドによってリレー ログを非同期的に読み取って解析し、リレー ログを実行します。転送を実行するための対応する SQL コマンド。スレーブはまずマスター データベースからバイナリ ログ データを読み取り、ローカルでスレーブ データベースに書き込みます。次に、SQL スレッドによってリレー ログを非同期的に読み取り、解析して、対応する SQL コマンドを実行します。
• bin_log アーカイブ ログ – データの永続化で機能します
  • データベースのデータ整合性を確保するために、すべての DDL および DML レコードをデータベースに記録します。
• undo_log ロールバック ログ – トランザクションの分離とアトミック性で動作します
  • UNDO ログは論理ログに属し、その名前は主にロールバックの役割を果たし、トランザクションのアトミック性を確保するための鍵となります。レコードはデータ変更前の状態です
  • データ変更の過程では、現在の操作とは逆の論理ログが同時にアンドゥログに記録されます。
  • トランザクションが実行されると、トランザクションのロールバックを確実にするために、コミット ロールバックが undo_log を実行します。
• redo_log REDO ログ – データの永続化における役割
  • REDO ログは、MySQL ストレージ エンジン InnoDB のトランザクション ログに属します。
  • 機能はバックアップと似ており、ダウンタイム後の復旧時には、redo_log を使用してデータを迅速に復元します。

MySQL の基礎となる知識ポイント

MVCC の原則:

• 同時実行性の高いトランザクションシナリオでロックフリーシナリオの使用を実現し、データファントム読み取りの問題を解決するため
• 実装原則:
  • キー: 隠しフィールド、現在の読み取り、スナップショット読み取り、トランザクション スナップショット、REDOLOG など。
  • 1. 非表示フィールド: db_row_id 行 ID、db_trx_id トランザクション ID、db_roll_ptr ロールバック ポインター
  • 2. Undo_log は、最初にデータをバックアップし、例外が発生した場合にデータをロールバックする操作として使用されます。
  • 3. 現在の読み取り: 読み取りロックの下で最新のデータを読み取ります。スナップショット読み取り: キャッシュと同様、必ずしも最新のデータであるとは限りません。
  • 4. トランザクションスナップショット + readView
    • トランザクション スナップショットは、テーブル共有スペースに作成されるトランザクション スナップショットであり、前後のトランザクションの順序を区別するために使用されます。
    • readView は、トランザクション スナップショットの読み取りによって生成された読み取りビューです。読み取り操作がトランザクションの前であれば表示されます。トランザクションの後であれば、表示されません。可視性を制御するために使用されます。