MySQL パフォーマンスの最適化により、データベースの実行が高速化されます。

データベースの最適化作業では、データをできるだけ小さくし、テーブルがハードディスク上で占有するスペースをできるだけ少なくすることが、最も一般的に使用され、最も効果的な方法の 1 つです。データが削減されるため、ハードディスクの読み取りおよび書き込み速度が相対的に向上し、クエリ プロセス中の小さなテーブルのコンテンツ処理に使用されるシステム リソースが少なくなります。同様に、インデックスが小さい列に設定されている場合、インデックスが占有するリソースは少なくなります。では、データベース管理者はどのようにして自分のデータを軽量化できるでしょうか?これについて著者は次のような提案をしています。

提案 1: Null 値は必ずしもスペースを占有しないわけではありません

ここで、著者はまず全員に教育します。データベース管理者の中には、NULL 値がシステム リソースを占有しないと信じている人もいます。実際、これは誤った理解です。データベースを設計するとき、彼らはフィールドのプロパティを NOT NULL に設定することを好みません。ユーザーが必要に応じてデータを入力できるようにします。著者は、このアプローチはデータベースのパフォーマンスに悪影響を与えると考えています。私の意見としては、可能であれば列を NOT NULL に設定するようにしてください。つまり、NULL 値は許可されません。そうすることで、後続の処理が高速化されると同時に、データ ストレージの観点から列ごとに 1 ビットを節約できるため、データの軽量化という目的を達成できます。実際の作業では、ユーザーがデータを入力する必要がない状況がある場合は、空ではない目的を達成するためにデフォルトのフィールドを使用することもできます。たとえば、給与システムでは、ユーザーの勤務年数をデフォルトで空白ではなく 0 に設定できます。もちろん、本当に NULL が必要な場合は、方法がありません。ただし、データベース エンジニアとしては、NULL 値の使用を避けるように努める必要があります。

提案 2: できるだけ小さいデータ型を使用します

データ型のサイズは、基になるテーブルのサイズにも影響します。たとえば、MEDIUMINT と INT の 2 つのデータ型は整数データの保存に使用できますが、保存できる精度は異なります。ただし、データを保存するという観点から見ると、前者は後者よりも約 25% 少ないストレージ容量を必要とします。このため、MEDIUMINT が使用できる場合は INT を使用しないでください。

また、データ長を定義する際は、ニーズに合わせてできるだけ短くする必要があります。たとえば、給与評価システムには従業員コーディングのフィールドがあります。企業の従業員コードが決定されている場合、それは 5 文字で構成されます。その後、フィールドを定義するときに、5 文字の長さを定義するだけで済みます。これにより、ストレージスペースを削減できるだけでなく、特定のデータ校正機能も果たすことができます。ユーザーが入力したコード長が5桁を超える場合はデータを保存できません。

特定のデータを保存するときに選択できるデータ型は数多くありますが、比較的多数の文字を定義することもできます。ただし、できるだけ小さいデータ型を選択すると、データの保存スペースを削減し、データの軽量化という目的を達成するのに役立ちます。これにより、データベースのパフォーマンスがさらに向上します。

提案 3: インデックスとデータテーブルのサイズの関係

著者は記事の冒頭で、より小さい列にインデックスを設定すると、インデックスが占有するリソースも少なくなると述べました。インデックスとデータテーブルのサイズも密接に関係していることがわかります。適切なインデックスを適切な場所に適切なタイミングで設定することで、データの軽量化という目的も達成できます。

通常、各データテーブルには複数のインデックスがある場合がありますが、多くの場合、メインインデックスは 1 つだけです。このため、各テーブルのメイン インデックスはできるだけ短く簡潔にする必要があります。これにより、データベースがより迅速に識別できるようになります。

もう 1 つの例は、可能な限りプレフィックスにインデックスを付けることです。たとえば、現在テーブルがある場合、特定の列にインデックスを設定する必要があります。そして、この列には特徴があり、最初の数文字に一意の接頭辞が付いています。この場合、すべてのプレフィックスではなく、このプレフィックスにしっかりとインデックスを付ける方がよいでしょう。 MySQL データベースでは、文字列の左端にインデックスを作成することがサポートされています。これは、データベースが特定のルールに従ってフィールドを 2 つの部分に分割することを意味します。分割後も前部分のデータを一意に保つことができる場合は、前部分にインデックスを設定するだけでよく、フィールド全体のデータにインデックスを設定する必要はありません。これにより、間違いなくインデックスが占有するリソースを削減し、減量の目的を達成できます。インデックスが短いほど、クエリ速度が速くなります。必要なハード ドライブのスペースが少なくなり、インデックス キャッシュにより多くのアクセスが節約されるためです。これにより、ハードディスクの検索回数が減り、クエリの効率が向上します。

最後に注意すべきことは、インデックスを悪用することはできないということです。インデックスを使用すると確かにデータ処理能力が向上しますが、インデックスにより追加のオーバーヘッドも発生します。メリットがオーバーヘッドよりも大きい場合にのみ、インデックスを使用してデータベースのパフォーマンスを向上させることができます。そうしないと逆効果になります。たとえば、テーブルを迅速に保存する必要がある場合、テーブルに設定されているインデックスが多すぎると、インデックスに副作用が生じます。この点に関して、著者は、主に検索列の組み合わせを通じてテーブルにアクセスする場合、インデックスを 1 つだけ設定するのが最善であると提案しています。もちろん、このインデックス部分は日常業務で最もよく使用される列であるはずです。複数のインデックスを使用する必要がある場合の最後の手段として、より多くのコピーを持つ列を使用してインデックス圧縮を向上させることが最善です。これにより、複数のインデックスの使用によるリソース消費の増加が軽減されます。

提案4: まだ「ふっくら」する必要がある部分を節約できません

女性は痩せるべきところは痩せて、ふっくらすべきところはふっくらしていなければなりません。実際、データベースにも同じことが当てはまります。ハードドライブのスペースを節約できる場合は、必ず保存してください。そして、節約できないものは、体重を減らすために合理化することはできません。場合によってはこれが裏目に出ることもあります。

著者は Varchar を例に挙げています。 MyISAM と同様、可変長列がない場合は、固定サイズのデータ​​型を使用することをお勧めします。固定長のデータ型が使用されますが、多くの場合、一定量の記憶領域が無駄になります。ユーザーが入力したデータが不十分で固定長が使用されている場合でも、データはこの固定長で保存されるためです。ただし、この場合、固定長を使用できる場合でも、固定長を使用する必要があります。この場合、ある程度のハードディスク容量が無駄になりますが、データのクエリ速度を向上させることができるためです。

データの軽量化では、どのような状況でもデータベースのパフォーマンスを向上させることはできないことがわかります。これは経費を削減して収益を増やすようなもので、この節約は最先端で節約されるべきです。そうしないと、お金を節約できないだけでなく、自分自身を傷つけることになります。平たく言えば、痩せるべきところは痩せて、ふっくらすべきところはふっくらするということです。この文だけ覚えておいてください。

提案 5: 減量目的を達成するためにテーブルを分割します

アリが食べ物を移動させるとき、食べ物が大きすぎて移動できない場合、アリは移動できるようになるまで食べ物を分割することがあります。これがケーキを分割する原理です。実際、この現象は日常業務でもよく見られます。たとえば、データベース テーブルがある場合、そこに多数のレコードがある場合、テーブルの許容速度は非常に遅くなります。この場合、テーブルは特定のルールに基づいて複数のワークブックに分割できます。たとえば、現在、企業の従業員の勤怠情報のコピーが存在します。このテーブルのクエリ、並べ替え、およびカウントを行うと、待ち時間が非常に長くなります。この時点で、部門ごとに異なるワークブックに分割し、それらに対して関連するデータ分析を実行できます。このとき、ワークロードは大きくなりますが、処理速度ははるかに速くなります

この原則によれば、データベースを最適化するときは、頻繁にスキャンされる大きなテーブルを 2 つ以上の表現に分割することが非常に有益です。たとえば、日常業務では現在、動的フォーマットのデータテーブルがあり、このデータがスキャンテーブルを使用している場合、これを使用して、比較的小さな静的フォーマットテーブル内の関連する行を検索します。

このテーブルの分割により、大きなケーキをいくつかの小さなケーキに分割して、その後のデータ統計と分析を容易にすることができます。もちろん、このエフェクトの質はこの分割のルールに直接関係します。望ましい効果を達成するためにテーブルを分割する方法については、これも比較的大きなトピックです。ここではスペースが限られているため、著者は多くの説明を省略します。おそらく今後の記事で、著者はこの命題をさらに詳しく説明するでしょう。

上記は、データベースの実行を高速化するための MySQL パフォーマンスの最適化の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。