概要
EXPLAIN の公式ドキュメント読んでも、情報量が多くて何を見ればいいのかよくわからないです。なので、どういうやつがやばいのかを示しておきます。
絶対に対処するもの
possible_key が NULL
WHERE 句に使っているカラムに、適切な INDEX を貼ってください。
できれば UNIQUE がいいけど、「 UNIQUE "っぽい" から」という理由で貼ると後悔します。「 UNIQUE でなければいけない」理由がない限りは、ただの INDEX に留めたほうが良いです。
type が、 system const eq_ref 以外
管理画面とか定時実行処理とかならセーフなもの
以下の type は、管理画面とか定時実行処理などのように、「1日数回しか実行しないこと」が保証されていれば、問題ないです。
「あるページにアクセスされるたびに実行される」とかだと、データ件数が増えると死ぬので、必ず改善してください。
reffulltextref_or_nullindex_merge
管理画面や定時実行処理からしかアクセスされないテーブルならセーフなもの
以下の"type"は、管理画面とか定時実行処理などのように、「1日数回しか実行しない場所からしか参照されないこと」が保証されていれば、問題ないです。
重要のなのは、「参照されない」ことで、SELECTであっても、頻繁にされてはいけません。
unique_subqueryindex_subqueryrangeindex
ALL は存在悪。許してはいけない。
ALL は、フルテーブルスキャンなので、存在悪です。 WHERE 句にインデックス貼っとけばなんとかなったりすることもあります。
できるだけ直したほうが良いもの
EXPLAIN の結果が4行以上
元のSQLが複雑すぎるので、直したほうが良いかもしれないです。
戦略レベルの設計でやらかしてる事が多いので、リファクタリングするのは難しいことが多いかもです。
key_len が1024以上
インデックスが張られているカラムが不適切かもしれないです。
INT や ENUM 型にすることを検討する。 INT 型にする場合は、「 settingテーブル（いわゆるマスタ）＋中間テーブル」という設計になる事が多いかもです。
調査したほうがいいかもしれないもの
ref が func
呼び出し元のスクリプト側で既に持っているデータで使えるデータがないかを調べましょう。
可能な限り、DBサーバの負担は減らしましょう。