他のすべてのデータベースと同様に、MySQLは複雑になる可能性があり、すべてのビジネスとタスクをすぐに停止する可能性があります。ただし、よくある間違いが、パフォーマンスに影響を与える問題のほとんどの根底にあります。
安定した一貫したパフォーマンスを提供することでサーバーが効率的かつ効果的に動作するようにするには、ワークロードまたは構成トラップの微妙な点によって引き起こされることが多いミスを排除する必要があります。
データ量が増えると、ますます複雑になります。したがって、効率的なエンドユーザーエクスペリエンスを提供するには、データベースを適切に最適化することが不可欠です。 MySQLパフォーマンスチューニングは、これらのデータベースの問題の解決策を提供するのに役立つため、究極のソリューションです。
MySQLパフォーマンスチューニング
この記事では、MySQLパフォーマンスチューニングの使用方法に関するいくつかの役立つヒントを紹介します。これにより、MySQLから最高のパフォーマンスを引き出すことができます。
ステップ1：MySQLをキューとして使用しないでください
気付かないと、キューやキューのようなパターンがアプリケーションに侵入する可能性があります。典型的な例は、電子メールを未送信としてマークし、送信してから、送信済みとしてマークすることです。これは一般的ですが、ほとんどのユーザーが無視する傾向がある、めったに目立たない問題です。
これらは、2つの主要なパフォーマンスの複雑さを引き起こします。
- ワークロードをシリアル化するため、タスクが並列シーケンスで完了するのを防ぎます。さらに、多くの場合、仕掛品と、かなり前に処理されたジョブの履歴データを含むテーブルが作成されます。これにより、通常、処理速度と処理速度が低下します。
- アプリケーションにレイテンシを追加し、MySQLにロードします。
ステップ2：ワークロードのプロファイルを作成する
ワークロードのプロファイリングは、サーバーがどのように機能し、サーバーがタスクの処理に費やす時間を理解するのに役立つため、不可欠です。これを行うのに役立つ最適なツールは、PerconaツールキットのMySQL EnterpriseMonitorsQueryアナライザーです。
注： Linuxユーザーのみが利用可能
ツールは、サーバーによって実行されたクエリをキャプチャし、応答時間の降順で並べ替えられたタスクのテーブルを返すことができます。
ワークロードをプロファイリングすると、さらに調整するための最もコストのかかるクエリが明らかになります。重要なのはクエリを発行するときの完了速度であるため、時間が最も重要です。
プロファイリングツールも同様のクエリをグループ化します。これにより、遅いクエリと速いクエリを確認できますが、何度も実行されます。
ステップ3：4つの基本的なリソースを理解する
CPU、メモリ、ディスク、およびネットワークは、データベースが機能するために必要な4つの基本的なリソースです。したがって、これらのリソースのいずれかが過負荷、脆弱、または不安定な場合、データベースのパフォーマンスが低下する可能性があります。
MySQLが完璧に機能するためには、前述の4つのリソースすべてが強力で安定していることを常に確認する必要があります。組織は通常、より多くのメモリスロットに対応できる高速CPUとディスクを備えたサーバーを選択します。
メモリの追加は、特にディスクにバインドされたワークロードで、パフォーマンスを桁違いに向上させる安価で簡単な方法です。これは不合理に思えるかもしれませんが、サーバーのワーキングデータセットを保持するのに十分なメモリがないため、多くのディスクが過剰に使用されています。
トラブルシューティングを行うときは、4つのリソースすべてのパフォーマンスと使用率を注意深く確認して、4つのリソースのパフォーマンス統計を判断してください。パフォーマンスを監視することは、ユーザーが何を改善する必要があるか、または何を交換する必要があるかを知るのに役立つため、重要です。この方法は、MYSQLのパフォーマンスの問題を解決するための最も迅速な方法の1つであるため、試すことができます。
ステップ4：結果を最も安いものから順にフィルタリングする
最適化の優れた方法は、最初に安価で不正確な作業を行い、次に小さい方のハードで正確な作業を行って、データセットを作成することです。
例：
地理的ポイントの特定の半径内で何かを探しているとします。プログラマーのツールボックスの最初のツールは、球の表面に沿った距離を計算するためのHaversine{大円}式です。
この手法の問題は、数式に多くの三角関数が必要であり、CPUに非常に敏感であるということです。その結果、計算の実行が遅くなり、マシンのCPU使用率が急上昇する傾向があります。
数式を使用する前に、レコードを合計の小さなサブセットに切り詰め、結果のセットを正確な円にトリミングします。円を含む正方形は、正確であろうと不正確であろうと、これを行う簡単な方法です。これにより、正方形の外側の世界がこれらの高価な三角関数のすべてに見舞われることはありません。
ステップ5：2つのスケーラビリティの死の罠を理解して理解する。
スケーラビリティは、多くの人が信じているほど曖昧ではないかもしれません。代わりに、システムが期待どおりにスケーリングしない理由を強調する方程式として表されるスケーラビリティの正確な数学的定義があります。
Universal Scalability Lawは、システムのスケーラビリティ特性を表現および定量化するのに便利な定義です。 2つの基本的なコストであるシリアル化とクロストークの観点からスケーリングの問題を説明します。
シリアル化された何かが発生するために停止しなければならない並列プロセスは、本質的にスケーラビリティーに制限があります。さらに、並列プロセスが作業を調整するために相互に通信する必要がある場合、それらは相互に制限します。したがって、アプリケーションを迅速かつ効率的に拡張できるように、シリアル化とクロストークを回避することをお勧めします。
ステップ6：構成に集中しすぎないでください
人々は構成の調整に多くの時間を費やしています。結果は通常、大きな改善ではなく、時には非常に損害を与える可能性があります。 MySQLに付属しているデフォルト設定は1つのサイズに適合し、何も構成する必要がないため、非常に古くなっています。
したがって、基本を正しく理解し、必要な場合にのみ設定を変更することが不可欠です。多くの場合、サーバーチューニングツールは、矛盾する情報でユーザーを誤解させる可能性があるため、お勧めしません。キャッシュヒット率やメモリ消費式など、危険で不正確なアドバイスがコード化されているものもあります。
ステップ7：ページネーションクエリに注意してください
パジネートするアプリケーションは通常、サーバーをひざまずかせます。多くの場合、最適化は他のユーザーインターフェイス自体にあります。たとえば、結果とリンクに正確なページ数を表示する代わりに、その情報を含むページへのリンクだけを表示することができます。したがって、元のページが過負荷になるのを防ぐことができます。
クエリ側では、制限付きのオフセットを使用する代わりに、もう1つの行を選択できます。[次のページ]をクリックすると、その最後の行を次の結果セットの開始点として指定できます。
ステップ8：統計を熱心に保存し、しぶしぶ警告します
アラートと監視は不可欠ですが、一般的な監視システムで発生するのは、誤検知の送信を開始することです。システム管理者は、ノイズを防ぐために電子メールフィルタリングルールを設定し、すぐに監視システムが役に立たなくなります。
システムで何が変更されたかを把握しようとすると喜んで取得できるため、可能な限りすべてのメトリックをキャプチャして保存することが重要です。また、奇妙な問題が発生した場合は、グラフをポイントして、サーバーのワークロードの変化を簡単に追跡できます。
人々は通常、バッファヒット率や1秒あたりに作成される一時テーブルの数などについて警告します。問題は、そのような比率に妥当なしきい値がないことです。さらに、適切なしきい値はサーバー間で、また作業の変化に応じて時々異なります。
その結果、明確で実行可能な問題を示す条件についてのみ、慎重に警告してください。たとえば、低いバッファヒット率は実用的ではなく、実際の問題を示すものでもありませんが、接続の試行に応答しないサーバーは、解決する必要のある実際の問題です。
ステップ9：インデックス作成の3つのルールを学ぶ
インデックスがどのように機能し、サーバーがそれらをどのように使用するかを知る方法はたくさんあるため、これはデータベースで最も誤解されているトピックです。インデックスは、適切に設計されていれば、データベースサーバーで3つの重要な目的を果たします。
- 単一行の代わりに、インデックスを使用すると、サーバーは隣接する行のグループを見つけることができます。多くの人は、インデックスの目的は個々の行を見つけることだと考えていますが、単一の行を見つけるとランダムなディスク操作が発生し、サーバーが非常に遅くなります。行のグループを見つけることは、一度に1つずつ行を見つけるよりもはるかに優れており、興味深いものです。
- また、サーバーは、行を目的の順序で読み取ることにより、並べ替えを回避できます。行の読み取りは、並べ替えとは異なり、はるかに高速で低コストです。
- インデックスを使用すると、サーバーはインデックスのみからのクエリ全体を満たすことができ、タブレットにアクセスする必要がまったくなくなります。これは、coveyインデックスまたはインデックスのみのクエリとしてさまざまに知られています。
ステップ10：同僚の専門知識を活用する
一人でやらないでよろしいですか？問題に戸惑い、論理的で賢明と思われることを行うことは、ほとんどの場合うまくいくかもしれませんが、常にではありません。したがって、代わりに、ツールセットやトラブルシューティングガイドを超えたMySQL関連のリソースのネットワークを構築してください。
人々は、メーリングリストやフォーラムなどに潜んでいる非常に知識が豊富です。さらに、会議、トレードショー、およびローカルユーザーグループのイベントは、洞察を得て、あなたを助けることができる仲間との関係を構築するための貴重な機会を提供します。
これらのヒントを補完するツールを探している少数の人は、MySQLおよびMySQLPercona監視プラグイン用のPercona構成ウィザードを確認できます。
構成ウィザードは、ベースラインの生成を支援します。サーバーに付属しているサンプルファイルよりも優れた新しいサーバーのmy.cnfファイル。
サーバーに付属しているサンプルファイルよりも優れたクエリアドバイザ。アドバイザーはSQLを分析して、ページネーションクエリなどの潜在的に破壊的なパターンを検出するのに役立ちます（ヒント7）。
Percona監視プラグインは、統計を熱心に保存し、しぶしぶ警告するのに役立つ監視およびグラフ作成プラグインのセットです（ステップ8）。これらのツールはすべて無料で入手できます。
パフォーマンスチューニングのメリット
主な利点は、サービスのサイズを適切に設定することで、過剰なプロビジョニングやコストの削減を回避できることです。また、データストレージの移動やサーバー容量の追加によってパフォーマンスが向上するかどうか、向上する場合はどの程度向上するかについての洞察も得られます。
データベースが正しく調整されると、優れた機能を備えた有益なパフォーマンス結果が得られます。不要なタスクの負荷を軽減するだけでなく、MySQLデータベースを最適化してデータをより高速に取得します。
他の設定は、ワークロードまたはハードウェアに応じて違いを生む可能性があります。目標は、MySQLのパフォーマンスをいくつか調整して、基本的でない設定を変更したり、ドキュメントを読んだりして、どの設定が重要かを理解するのに時間をかけずに、正常なMySQL構成をすばやく取得できるようにすることです。
結論
結論として、パフォーマンスチューニングには多くの利点があり、サーバーの効率を向上させるために大量のデータを処理する場合に推奨されます。この記事に記載されているヒントに従うことで、サーバーとデータベースでMySQLのパフォーマンスチューニングを快適に実行できるようになります。