MySQL
MySQLのパフォーマンスのヒント
サーチ…
ステートメント最適化の選択
以下は、私たちがクエリの時間を短縮するのに役立つ、MySQLで選択されたクエリを書いている間のヒントです。
大きなテーブルのどこでどこを使用するかによって、where句のカラムがインデックスかどうかを確認する必要があります。例： - 従業員から*を選択します。ここでuser_id> 2000. user_idがインデックス化されている場合、クエリatlotの評価がスピードアップされます。索引は、結合および外部キーの間にも非常に重要です。
テーブルから全体のデータを取得するのではなく、より小さなセクションのコンテンツが必要な場合は、limitを使用してみてください。むしろ、従業員からEx： - Select *を書いてください。 lakhsから最初の20人の従業員だけが必要な場合は、limit Ex： - Select *を従業員LIMIT 20から使用してください。
また、結果セットに必要な列名を指定して、クエリを最適化することもできます。むしろ、従業員からEx： - Select *を書いてください。テーブルに列がたくさんあり、それらのうちのいくつかのデータしか持たない場合は、データが必要な列名を記述するだけです。例： - 従業員のID、名前を選択します。
where句でNULLを確認するために使用している場合は、Indexカラム。 SELECT * FROM tbl_name WHERE key_col IS NULLのような文がある場合。 key_colが索引付けされると、照会はより高速に評価されます。
InnoDBテーブルのストレージレイアウトの最適化
- InnoDBでは、長いPRIMARY KEY（長い値を持つ単一の列、または長い合成値を形成する複数の列のいずれか）を持つと、多くのディスク領域が無駄になります。行の主キー値は、同じ行を指すすべての2次索引レコードに複製されます。主キーが長い場合は、AUTO_INCREMENT列を主キーとして作成します。
- CHARではなくVARCHARデータ型を使用して、可変長文字列を格納するか、NULL値が多い列に格納します。 CHAR（N）列は、文字列が短くても値がNULLであっても、データを格納するために常にN文字を使用します。テーブルが小さくなると、バッファプールが良くなり、ディスクI / Oが減少します。
COMPACT行形式（デフォルトのInnoDB形式）とutf8やsjisなどの可変長文字セットを使用する場合、CHAR（N）列は可変サイズの領域を占めますが、それでもNバイト以上です。
- 大きな表、または反復するテキストまたは数値データが多数含まれている場合は、COMPRESSED行形式の使用を検討してください。バッファー・プールにデータを持ち込むため、またはフル・テーブル・スキャンを実行するためには、より少ないディスクI / Oが必要です。恒久的な決定を下す前に、COMPRESSEDとCOMPACTの行形式を使用して達成できる圧縮量を測定します。 注意：ベンチマークは2：1圧縮よりも優れていることはめったにありません。また、COMPRESSEDのbuffer_poolには多くのオーバーヘッドがあります。
- データが安定したサイズに達するか、または増加するテーブルが数十または数百メガバイト増加したら、OPTIMIZE TABLEステートメントを使用してテーブルを再構成し、無駄なスペースを圧縮してください。再編成された表は、フル・テーブル・スキャンを実行するために必要なディスク入出力は少なくなります。これは、索引の使用率の向上やアプリケーション・コードのチューニングなどの他の技法が実用的でない場合に、パフォーマンスを向上させる簡単な手法です。 注意 ：テーブルサイズにかかわらず、OPTIMIZE TABLEはめったに実行されません。これはコストがかかり、価値があるほどテーブルを改善することはめったにないためです。 InnoDBは、B + Treesをたくさんの無駄なスペースから解放しておくのが妥当です。
OPTIMIZE TABLEは、表のデータ部分をコピーし、索引を再構築します。この利点は、索引内のデータのパッキングが改善され、表領域およびディスク内の断片化が減少することによるものです。利点は、各テーブルのデータによって異なります。一部のユーザーには大きな利益があり、他のユーザーには大きな利益がないことや、次にテーブルを最適化するまで、時間の経過と共に利益が減少することがあります。表が大規模である場合や、リビルド中の索引がバッファー・プールに収まらない場合、この操作は遅くなる可能性があります。多くのデータをテーブルに追加した後の最初の実行は、しばしば後の実行よりもはるかに低速です。
複合インデックスの作成
多くの場合、複合インデックスは単一の列を持つインデックスよりも優れたパフォーマンスを発揮します。最適なコンポジットインデックスを作成するには、この順序で列を挿入します。
-
=WHERE句の最初の列。 （たとえば、WHERE a=12 AND b='xyz' ...INDEX(a,b,...)WHERE a=12 AND b='xyz' ...） -
IN列（s）;オプティマイザは索引を飛び越えることができます。 - 1つの "range"（例えば、
x BETWEEN 3 AND 9、name LIKE 'J%'）最初の範囲の列を超えて何も使用しません。 -
GROUP BYすべての列を順番に -
ORDER BYすべての列。すべてがASCか、またはすべてがDESCか、または8.0を使用している場合にのみ機能します。
注と例外：
- 列を複製しないでください。
- 適用されない場合はスキップしてください。
-
WHEREすべての列を使用しない場合は、GROUP BYなどに進む必要はありません。 -
WHERE無視して、ORDER BY列のみを索引付けすると便利な場合があります。 - 関数内の列を「隠す」ことはできません（例：
DATE(x) = ...インデックスではxを使用できません）。 - '接頭辞'の索引付け（例えば、
text_col(99)）はtext_col(99)ないでしょう。傷つくことがあります。