Mysqlにて、クエリのチューニングを集中して行っているため、
せっかくなので気づいた点等をまとめていきたいと思います。
まず、現在実際に行っている、
既に完成しているアプリのSQLチューニング手順。
1. 画面ベース、機能ベースで速度を目視チェック
→体感速度で遅いと感じる画面、機能をピックアップ。
ただし、DBから取得するデータの量や内容によって速度が大幅に変わることはままあるので、
同じ画面、機能でも、データ量や内容のパターンを変えてチェック。
（※一般的に、画面表示までに3秒以上かかるサイトは遅いとされる）
2. 画面遷移時に流れているSQLの速度を計測
→システム等のログにSQLを書き出すようにし、MysqlWorkbench等のツールでSQLを実行して、実行速度を計ってみる。
3. EXPLAIN 関数 を使って遅い要因を判定
→2.のSQLを「EXPLAIN」関数付きで実行してみる
→結合INDEXが張れていない、「using filesort」（=ソート時にIndexが適用されてない）使っている、等の遅くなる要因がないかチェック。
4. 遅いSQLと要因が分かったら、チューニング
→チューニング方法はケースバイケースだが、大概下記の原因・・・なように思う。
・必要なIndexが張れてない
（"結合条件として並んでいる順番で"張れていない場合は、Indexが無効になってたりする・・・）
・不要なデータまで検索対象に含めている
（不要なカラムデータまで取得している、もしくは、絞り込み条件の抜け漏れ）
・ソート関数や集約関数
（ORDER BY や GROUP BY。特に、対象データが多い場合や、
関数のKeyにしているカラムにIndexが張れていなかったりする場合）
・無暗やたらなViewの使用、ネスト
（Viewのご利用は計画的に。
むやみにViewを作ったり、ネストさせるのはやめたほうが良いです。。。
多少複雑なSQLにする必要があっても、直TBLアクセスのほうが、
データ量が多くなった場合に困らない事が多いかと。経験上。）
5. チューニングが終わったら、検証
→予め、実装前の画面表示速度を計測しておき、チューニング前後の速度比較をする。
（SQLが多少早くなっても、画面表示が遅い場合、プログラム側の問題があることも・・・）
→影響範囲のチェック
（複数の画面処理から呼ばれているSQL（もしくは、DBアクセス処理）を修正した場合、
他の画面表示時に不具合が発生したり等しないよう、影響範囲のチェックは抜け漏れなく行う）
その他、細かい気付き等はまた別途載せるかもしれないし、
載せないかもしれない。
harupapa