全表スキャンを避けます
クエリの最適化は、全表スキャンを回避しようとしてください、あなたは最初の場所と順番に関与列でインデックス作成を検討すべきです。
NULL値を避ける分析
：フィールドwhere句で決定されたヌル値に避けるべきであるが、例えば、エンジンがインデックスとフルテーブルスキャンを使用して放棄する原因となり
NUM TがNULLである場所からSELECT ID
、そのテーブルを確実にするために、0 NUMのデフォルト値を提供することができます：NUM列の値は、このクエリは、nullでない
= 0 TからSELECT ID WHERE NUM
判決と同等のものを避けます
句！=または<>オペレータでは避けるべきで、そうでない場合はエンジンがインデックスと全表スキャンを使用してあきらめます。
使用しないでくださいまたはロジック
：回避またはwhere句で条件を結合するために使用されるべきで、エンジンがインデックスと全表スキャンなど、使用してあきらめてしまいます
TからSELECT ID NUM = NUM = 10か20がある
：できたこのクエリ
TからSELECT IDを10 = NUM
ユニオンすべて
IDからSELECT = 20 T WHERE NUMであります
注意ではなく、ロジックで
：ではないに注意して使用すべきで、それ以外の場合のような、フルテーブルスキャンにつながる
上記WHERE T1からIDを述べにSELECT NUM（T2上記ID> 10上述ID述べSELECTからWHERE）
インデックスを使用しないで、外側のクエリは、フルテーブルスキャンであろう。この場合に。あなたが変更されてもよい：
SELECT T1のID（> 10からID SELECT ID T1）= t1.idのt2.idのT2
ケースインデックスが使用されるが、大幅クエリの効率を向上させることができます。
ファジークエリを注意してください
次のクエリは、全表スキャンになります：
「ABC %%」のような名前TからSELECT ID
の条件は、トン名「などからIDを選択することができるかどうファジー問い合わせが必要であるのABC％」 ファジー問い合わせに、この時間インデックスが使用されます。最初に一致したロジックが必要な場合は、フルテキスト検索エンジン（弾性検索、Luceneと、Solrの、など）を使用することをお勧めします。
クエリ内の計算フィールドを避けます
エンジンがインデックスと全表スキャンを使用してあきらめてしまうWHERE句、内のフィールドオペレーションの表現を避けるべきです。例えば：
T / 2 = 100からNUMがSELECT ID
：読むべき
SELECT IDをNUM = 100 * 2 Tから
クエリを回避するために、フィールドの動作条件の機能
エンジンがインデックスとフルテーブルスキャンを使用してあきらめてしまうwhere句、内のフィールドの操作機能を避けるべきです。例えば：
ストリングからT（名前、lは、3）= 'ABC' SELECT ID -名前ID ABCに始まりが
読んでください：
'％ABC'のようなT WHERE名からSELECT IDを
WHERE句「=」左の注意事項
where句の関数、算術演算、またはその他の表現ではないが行う「=」左、またはシステムが適切に索引付け機能しない場合があります。
複合インデックスを使用します
インデックスを使用しての条件として、フィールドでは、インデックスは複合インデックスであるならば、あなたはシステムを確保するための条件として、最初のフィールドにインデックスを使用する必要があり、インデックスを使用してそれ以外のインデックスは使用されません、とすべきである可能な限りフィールドの順序は、順序インデックスと一致してみましょう。
異議なしでクエリを定義しないでください
そのような空のテーブル構造を作成する必要として、意味がないクエリを記述しないでください：
1 = 0 WHERE tから#tをINTO SELECT COL1、COL2
このコードは、任意の結果セットを返しませんが、システムリソースを消費し、これによって交換する必要があります：
（...）テーブルに#tを作成します。
存在します
代わりに、使用の多くの場合に存在する良い選択です：
WHERE（BからNUMを選択）でAからNUM NUMを選択
次の文と置き換えた。
（。SELECT 1 NUM = a.num Bから）NUMがAから存在SELECT
インデックスが無効である可能性があります
すべてのインデックスが有効なクエリわけではありません、SQLクエリの最適化は、テーブル内のデータに基づいて行われるインデックスは、重複データの大規模な数を示したときに、SQLクエリはインデックスを使用して行っていないことがあり、テーブルなどのフィールドのセックスを持って、男性、女性のほとんど各半分、セックスのクエリ効率指標の上に構築された場合でも、また何の効果はありません。
フォームフィールドの種類を選択
場合にのみ、クエリとの接続のパフォーマンスが低下しますし、ストレージのオーバーヘッドが増加します文字、のために設計することがないように、数値フィールド、情報を含む数値フィールドの使用を確認します。一度だけ文字列内の各文字を比較することにより、クエリとの接続1を処理し、数値の比較のために、エンジンが十分にあるためです。
すべての可変長フィールドの小さな収納スペースの最初の、あなたは検索効率の比較的小さなフィールドで、クエリに続いて、ストレージスペースを節約することができますので、代わりに炭の活用可能性のvarchar型は、明らかに高いです。
クエリ構文のフィールド
未満でフィールドのいずれかを返さない、代わりに「*」の分野の特定のリストで、T *からどこかの選択は使用しないでください。
インデックスに依存しない最適化
*すべてのキーワードは、労働組合、労働組合を使用しないようにしよう、使用しないでください、判決と同等のものを使用しようと、使用したり、キーワードしないようにしよう。
表には5以下で推奨していない参加します。5つ以上の場合は、テーブルの設計を考えます。（インターネットアプリケーション）
インラインアウトリーチの使用よりも表接続。
データに接続された外部ベースが存在します。このように左B、ベースデータがAであるジョイン
内側全体接続、結果セットを取得する接続状況に応じて接続を完了するためにデカルト積を使用して、B、ない基本データを結合します。
大規模なデータテーブルの順序は、ページングクエリを実行すると、ページ数が多すぎる場合、ページングロジックの完了とサブクエリを使用します。
*表から1000000 SELECT、10制限
WHERE表IDからSELECT *を（100000 PK、10を制限表から選択）