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 サイトの他の関連記事を参照してください。