MySQLの運用・保守の最適化-mysql

逐語大きな柱  https://www.dazhuanlan.com/2019/08/17/5d576c62e39a9/

ストレージエンジンタイプ

 •MyISAMテーブルの速度と高速応答。テーブル・レベルのロッキングは致命的な問題です。
 •InnoDBの主流のストレージエンジン
   •行レベルのロック
     •結果セットの中で定義されているものの影響に注意を払うようにしてください
     更新をもたらす•行レベルのロックのオーバーヘッドが、それは通常の価値。
   •トランザクションがコミット
     I O /効率の考慮強化する•
     安全の•考慮
 •ヒープメモリエンジンが
   ロック状態と頻繁な更新の下に存在し続けるの•大規模な読書状況

メモリ使用量の考慮事項

 •理論的には、より多くのメモリは、メモリ読み出しでより多くのデータが発生し、高効率の
 •は、ハードウェアリソースの配分で考慮に現実とボトルネックを取るために
 •ホット・データを理解することを学ぶ、およびホット・データのメモリとして
   、いわゆるホットデータ•、データのほとんどがアクセスされています。
   •データベースへのアクセスは、いくつかのデータが頻繁に読まないと書き込みが、より稀にデータを読み書きしている、通常は不均一です。
   •異なるルールホットデータ、および測定指標を作ることを学びます。
     •ホット・データのサイズは、理論的には、可能性、成長傾向として、ホットデータは、私たちはより良いビジネスを満たすことができます。
     •満足度応答は、回答率は高いほど良い満たすことができます。
     •例えば、最終更新時刻によれば、インジケータはホットスケールモデルの異なる定義を訪問、繰り返し訪問、及び他のホットデータ、及び推定されたデータの合計数を定義します

パフォーマンスとセキュリティの考慮事項

 •データの提出
   •= 1、自動的にそれぞれ提出、安全で、I / Oの圧力innodb_flush_log_at_trx_commit
   •のinnodb_flush_log_at_trx_commit = 2あたりが自動的に提出し、安全性のわずかな影響、I / Oの強いベアリング。
 •ログ同期
   •同期-binlogの= 1各自動更新、安全で、I / Oの圧力
   •同期-binlogの= 0に自動的に更新されたキャッシュの設定、失われたデータと同期遅延リスクの存在、高いI / Oの運搬能力。
 •パフォーマンスと逆の場合に固有のセキュリティ、ビジネスにおける需要のレベルを選択するという決定は、
   •機会が何時のセキュリティに焦点を当て、パフォーマンスを重視するものを区別することを学ぶ
   •異なるとセキュリティポリシー管理データベースの異なるレベルを学習

圧力ストレージの最適化

 •シーケンシャルリードとパフォーマンスを書きがランダム読み取りよりもはるかに高く、書き込み
 ログデータの読み取りまたはシーケンシャル使用して書き込むことができます
 •異なる物理ディスクへの書き込みデータとランダムデータシーケンスの書き込み、提供、I / Oの圧力を緩和するのに役立ちますあなたのI / Oは、シーケンシャルライトからの圧力ができます(順序に起因するランダムアクセス干渉を書き込むことはできませんが、順序が書き込まれるが、I / O操作の仕方をして)あなたは確か。

運用・保守監視システム

 •システム監視
   •サーバ・リソースの監視
     。•CPU、メモリ、ディスク容量、I / Oの圧力
     しきい値アラームの設定•
   •サーバのトラフィック監視
     、外部ネットワークトラフィック•を、ネットワークトラフィック
     •しきい値アラーム設定
   •接続状態監視
     しきい値、の各設定•ショーPROCESSLISTを分のモニタリングは、記録がしきい値超えた
 監視•アプリケーション
   •スロークエリ監視
     •スロークエリログ
     がある場合は、複数のデータベースサーバを•、要約レビュー・メカニズムがあるはずです。
   •監視リクエストエラー
     •高周波用途、比率変更散発データベース接続エラーまたは実行エラーが、エラーメッセージがログに記録され、毎日のビューが表示されます。
     少数であれば•散発的なエラーは、対処が、多くの場合、傾向を監視する必要はできません。
     •悪質な入力があるだろう、欠乏を定義する境界入力は間違いの実現につながり、必要性は、この動作に基づいて、悪質な侵入検知を防ぐために。
   •監視マイクロ遅いクエリ
     、クエリのより0.01秒•高同時実行環境をご覧下さい。
   •の頻繁なモニタリング
     •書き込み動作、ベースのバイナリログ、定期的に分析。
     •読み出し動作、ログのフロントエンドは、サンプリングDBパッケージコードを増加させ、かつ実行時間を出力します。
     •頻繁に要求の分析は、開発フレームワークのさらなる最適化のための基礎となっている
     最高の最適化が要求の数を減らすことです•!

要約:

   •監視制御およびデータ解析は、すべての最適化の基本です。
   •運用データのない監視がありませんが、最適化にジャンプしないでください!
監視は、監視のために多くのオーバーヘッドを追加しない、あまりにも多くの余分な負荷を発生しないように注意する必要があります

おすすめ

転載: www.cnblogs.com/petewell/p/11417815.html