MySQL ビッグ データ クエリのパフォーマンス最適化チュートリアル (写真)

MySQL のパフォーマンスの最適化には、テーブルの最適化とカラムの種類の選択が含まれます。テーブルの最適化は何に分類できますか? 1. 固定長と可変長を分離する。 2. 一般的に使用されるフィールドと一般的ではないフィールドを分離する。 3. 相関統計が必要な 1 対多のフィールドに冗長フィールドを追加する。与 I. テーブルの最適化と列の型の最適化:

1、固定長と ID int などの長さの分離は 4 バイトを占め、Char (4) を考慮します。 4 文字の長さも固定されており、時間、つまり各単位値が占めるバイト数も固定です。コアフィールドと一般的に使用されるフィールドは固定長で構築し、テーブルに配置する必要があります。 varchar、テキスト、BLOBなどの可変長さフィールドは、別のテーブルに配置され、プライマリキーを使用してコアテーブルに関連付けられているのに適しています。 commenty一般的に使用されるフィールドと珍しいフィールドを分離する必要があります。

3. 関連する統計を必要とする 1 対多フィールドに冗長フィールドを追加します。 ： 以下の効果を見てください。 下 各セクションには、n 個の投稿があり、ページ情報の下の投稿数とホームページの下の投稿数が表示されます。

これはどうですか? BOARD テーブルに列が 2 つしかない場合は、ブロックを取得して、投稿テーブルを確認し、投稿数で投稿グループからカウント (*) を選択する必要があります。

2. 列の型の選択

1. フィールドの型の優先順位

s ' ' s ' を通して ‐ ‐ ‐ ‐ と一緒に、

>blob,text整数型：固定長、国・地域不問、文字セットの違いはありません。例: Tinyint 1,2,3,4,5 & lt;-& gt; では、スペースからの a、b、c、d、e

はすべて 1 バイトを占有しますが、ソートによって順序付けされます。前者の方が速いです。その理由としては、文字セットと照合順序セット (つまり、並べ替え規則) を考慮する必要があることが考えられます。タイムゾーンを考慮すると、SQL を書くときに都合が悪くなります。 `2018-08-08`;

enum は内部的に保持され、Table の変換 (ソートなどの操作のみが実行可能) になります。ディスク上)

添付ファイル: 日付/時刻の選択に関して、マスターの明確な意見は、タイムスタンプを保存するために int unsgined not null を直接選択することです。 ️

tinyint()、固定長 1 バイト

2. 寛大にしないでください (smallint varchar(N) など)。

理由: 大きなバイトはメモリを無駄にし、速度に影響します。

年齢を例に取ると、 tinyint unsigned not null は 255 歳を保存できますが、これで十分です。 int を使用すると 3 バイトが無駄になります。

varchar(10) と varchar(300) に格納される内容は同じですが、varchar(300) はテーブル結合クエリ中により多くのメモリを消費します。

3. NULL() の使用は避けてください

理由: NULL はインデックス作成に適さないため、特殊文字でマークする必要があります。

実際にはディスク上でより多くのスペースを占有します (MySQL5.5 では null が改善されましたが、クエリはまだ不便です)

3. インデックス最適化戦略

1. インデックスの種類

1.1 B -tree インデックス

名前はBTREEインデックスで、大きな側面で使用されるバランスツリーですが、具体的な実装は少し異なります。たとえば、厳密に言うと、NDBエンジンはT-TREEを使用します

が、B-treeシステムは抽象化できます。 「ソートされた高速クエリ構造」として理解されます。

1.2 ハッシュ インデックス

デフォルトはメモリ テーブル内のハッシュ インデックスであり、ハッシュの理論的なクエリ時間計算量は O(1) です。

質問: ハッシュ検索は非常に効率的であるため、なぜハッシュ インデックスを使用しないのでしょうか?

答え:

1. データがディスク上に配置されている場合、例として主キーを ID として、ID が増加するにつれて、その ID に対応する行がランダムになります。ディスク上の場所はランダムになります。

2. 範囲クエリは最適化できません。

3. 接頭辞インデックスは使用できません。たとえば、btree では、フィールド列の値は "helloworld" であり、インデックス クエリ x=helloworld は当然インデックスを使用でき、x=hello もインデックスを使用できます。 (左側のプレフィックスインデックス)。

4. 並べ替えを最適化することはできません。

5. 行バッキングが必要です。つまり、インデックスを通じてデータの場所を取得するには、テーブルに戻ってデータを取得する必要があります。 2、BTREE インデックスのよくある誤解

2.1 次のような WHERE 条件にインデックスを追加します。 where cat_id = 3 and Price & gt; 3 番目の列 (100 元を超える商品) をクエリします。

誤解: cat_id とprice の両方にインデックスを追加します。

エラー: cat_id または Price インデックスのみを使用できます。これらは独立したインデックスであり、同時に使用できるのは 1 つだけです。

2.2 複数の列にインデックス (結合インデックス) を作成した後、どの列がクエリされてもインデックスは機能します

誤解: インデックスが複数列インデックスで機能するには、左側のプレフィックス要件を満たす必要があります。

インデックス (a、b、c) を例に挙げます (順序に関係していることに注意してください)

4. インデックスの実験

use out of using インデックス (a、b、c)例: select * from t4 where c1=3 and c2 = 4 and c4> 5 and c3 = 2 インデックスとは:

Select * from T4 where c1 = 3 and c2 = 4 and C4 & GT; : 4)

5. クラスター化インデックスと非クラスター化インデックス

Myisam と innodb エンジン、インデックス ファイルの類似点と相違点

Myisam: news.myd と new.myi の 2 つのファイルで構成されます。インデックス ファイルとデータ ファイルは別のものであり、非クラスター化インデックスと呼ばれます。プライマリ インデックスとセカンダリ インデックスはどちらも物理行 (ディスク上の場所) を指します。

innodb: インデックスとデータは一緒にクラスター化されているため、クラスター化インデックスになります。データ行は innodb のプライマリ インデックス ファイルに直接保存され、セカンダリ インデックスはプライマリ キー インデックスへの参照を指します。

注: innodb の場合:

1. 主キーインデックスはインデックス値を格納し、行データをリーフに格納します。

2. 主キーがない場合は、一意のキーが主キーとして使用されます。

3. 一意のない場合、システムは主キーとして内部 ROWID を生成します。

4. innodb と同様に、主キーのインデックス構造には、主キーの値と行データの両方が格納されます。この構造はクラスター化インデックスと呼ばれます。

クラスター化インデックス

利点: 主キーによるクエリエントリが比較的少ない場合、行を戻す必要はありません (データは主キーノードの下にあります)

欠点: 不規則なデータが挿入されると、頻繁なページ分割の原因になります

関連記事:

Mysql パフォーマンスの最適化

関連ビデオ:

MySQL 最適化ビデオ チュートリアル

以上がMySQL ビッグ データ クエリのパフォーマンス最適化チュートリアル (写真)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。