MySQL 最適化の最も基本的な操作を要約します。-mysql チュートリアル-php.cn

最適化のアイデア

MySQL 最適化の詳細な手順は次のとおりです。

データテーブルの構造を確認し、不完全な設計を改善します
本業を実行し、よく使われるデータベースクエリSQLを収集
クエリSQLを分析し、適切に分割し、インデックスを追加するなどしてクエリを最適化します
SQLを最適化しつつ、最適化を行いますコードのロジック

NULL 値を使用しないようにしてください## なぜなら、テーブルを作成するときに、作成された値にデフォルト値を設定しないでください。MySQL はデフォルトで NULL

に設定されます。では、なぜ

NULL を使用するのは良くないのでしょうか?

NULL

NOT NULLNOT IN
およびその他の負の条件付きクエリは、NULL 値がある場合に常に空の結果を返し、クエリは # でエラーが発生しやすくなります。 ##NULL 列 NULL
NULL であるかどうかを決定するためのフラグとして追加のバイトが必要です。NULL
MySQL は、NULL
となる可能性のあるカラムのクエリを最適化するのが難しいため、以前は遅延していたフィールドについては、手動でデフォルト値の空の文字列を設定し、0を追加します。

この方法では MySQL のパフォーマンスはあまり向上しませんが、これは良い習慣であり、小さなことから大きなことまで見ることができるため、これらの詳細を無視しないでください。

インデックスの追加

頻繁にクエリされるフィールドについては、インデックスを追加してください。インデックスがある場合とない場合では、クエリ速度が 10 倍以上異なります。

一般的に、各テーブルには主キーが必要です

クエリによく使用されるフィールドにはインデックスを付ける必要があります
varchar
クエリに複数の条件がある場合、インデックスを含む条件が優先されます
LIKE
データベースレベルでテーブル間の関係を制限しないようにしてください
テーブル間に制約がある場合、追加、削除、クエリの SQL ステートメントは単純になりますが、挿入などの悪影響が生じます。データベースの操作時に制約がチェックされます (ただし、制約は手動で無視できます)。これは、データベース層にビジネスロジックを書き込むことと同等であり、保守が不便です。

テーブルフィールド構造を最適化する

データベース内の整数で表現できるデータには文字列型を使用しないでください。varchar## を使用する必要がありますか? # または

char

フィールドの可能な値によって異なります。データベース内に大量のデータがある場合、この種の最適化は実現できないことが多いため、データベース設計の前に最適化を設計することをお勧めします。

可能な値が非常に限られている列の場合は、

VARCHAR

の代わりに

を使用します。たとえば、モバイルデバイスを記録する場合、プラットフォームの場合、値は android、ios の 2 つだけです。android を表すには 0 を使用し、ios を表すには 1 を使用できます。この列はコメント化する必要があります
- を使用しないのはなぜですか?
- 拡張の難しさ。たとえば、後でモバイルプラットフォームに ipad が追加されましたが、これは混乱を招くでしょうが、tinyint は単に 2 を追加するだけであり、 ENUM はコード内で扱うのが非常に奇妙で、整数として扱われるか文字列として扱われるかは言語によって異なります。このメソッドでは、各値の意味をデータベースコメントまたはコードに記述する必要があります。
- これらの固定長文字列には、
(郵便番号など) は常に 5 桁です
長さが不明な文字列の場合は、varchar
を使用し、bigint## を乱用しないでください。 #、レコードなど記事数テーブルの id
int を使用し、上限は 21 億記事で十分です。データベースパラダイムを適切に打ち破り、クエリを回避するために冗長フィールドを追加します。テーブル接続 をクエリする場合、int 型は
よりも高速である必要があります。整数の比較は基になる演算子を直接呼び出すことで実現できますが、文字列型の比較は文字ごとに行われます。

固定長データクエリは、固定長データとデータ間のオフセットが固定されており、次のデータのオフセットを計算するのが簡単であるため、可変長データクエリよりも高速です。可変長データの場合、次のデータのオフセットをクエリするには、さらに 1 つの手順が必要です。しかし。固定長データは、より多くのストレージ領域を浪費する可能性があります。

大規模なテーブルの分割

データ量が近い将来 500 万を超える可能性があるテーブルや、急速に増加するテーブルの場合は、必ず事前にテーブルを垂直または水平に分割してください。ボリュームが 100 万を超えると、クエリ速度が大幅に低下します。

データベース設計の初期段階でサブデータベースとサブテーブルの計画を最終決定するようにしてください。そうしないと、コードが大幅に複雑になり、後で変更することが困難になります。

垂直テーブルパーティショニングは日付などの外部変数に基づき、水平テーブルパーティショニングはテーブル内の特定のフィールドの関係に基づき、ハッシュマッピングを使用してテーブルを均等な部分に分割します。

サブデータベースとテーブルサブデータベースの前提条件は、クエリステートメントを実行する前に、クエリ対象のデータがどのサブデータベースとどのサブテーブルに分類されるかをすでに知っていることです。

クエリステートメントの最適化

これは、多くのシステムデータベースのボトルネックの原因となります。

単純なクエリを使用し、テーブルリンクの使用を避けてください。
フルテーブルスキャンを回避するようにしてください。フルテーブルスキャンを引き起こすステートメントには次のものがありますが、これらに限定されません:
- where 句の条件は常に true または空です
- Use LIKE
- 不等号演算子 (<>, !=)
- を使用しますis null
- を含む列をクエリするインデックス以外の列で or
を使用して複数の条件でクエリを実行する場合、単純なクエリ条件またはインデックス列クエリを先頭に置いてください。
クエリを実行する必要がある列を指定してください。select を使用するのを怠らないでください。*
- 指定しない場合は、一方で、冗長なデータが返され、帯域幅などを占有します。
- 一方、MySQL がクエリを実行するとき、フィールドがない場合は、最初にテーブル構造内のフィールドをクエリします。 .
大文字のクエリキーワードは小文字のクエリキーワードよりも若干高速です
サブクエリを使用すると一時テーブルが作成され、リンク (JOIN) やユニオン (UNION) よりも若干遅くなります。 )
インデックスフィールドでクエリを実行する場合は、クエリ結果をキャッシュするのに不都合なため、データベース関数を使用しないようにしてください。
データが 1 行しかない場合は、LIMIT 1 を使用してください。データが多すぎるため、LIMIT を適切に設定してページングクエリを実行してください。