Skip navigation links
MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 4 最適化 :: 4.2 SELECT およびその他のステートメントの最適化
4.2.1 EXPLAIN を使用して、クエリーを最適化する »
Section Navigation      [Toggle]

4.2. SELECT およびその他のステートメントの最適化

[+/-]

4.2.1. EXPLAIN を使用して、クエリーを最適化する
4.2.2. クエリパフォーマンスの推定
4.2.3. SELECT クエリーの速度
4.2.4. WHERE 節最適化
4.2.5. Range 最適化
4.2.6. インデックス結合最適化
4.2.7. コンディションプッシュダウン最適化
4.2.8. IS NULL 最適化
4.2.9. LEFT JOIN と RIGHT JOIN 最適化
4.2.10. 入れ子ループ join アルゴリズム
4.2.11. 入れ子結合最適化
4.2.12. 外側 Join 単純化
4.2.13. ORDER BY 最適化
4.2.14. GROUP BY 最適化
4.2.15. DISTINCT 最適化
4.2.16. IN/=ANY サブクエリーの最適化
4.2.17. LIMIT の最適化
4.2.18. optimizer_switch を使用したオプティマイザの制御
4.2.19. テーブルスキャンを避ける方法
4.2.20. INFORMATION_SCHEMA 最適化
4.2.21. INSERT ステートメントの速度
4.2.22. UPDATE ステートメントの速度
4.2.23. DELETE ステートメントの速度
4.2.24. その他の最適化のヒント

第 1 にすべてのステートメントに影響を及ぼすことが 1 つあります。アクセス権システムの設定の複雑性が増すほど、オーバヘッドも増加します。GRANT ステートメントを発行する際に単純なアクセス権を使用することで、クライアントがステートメントを実行する際の MySQL にアクセス権確認オーバーヘッドを減らすことができます。たとえば、テーブルレベルやカラムレベルの権限を許可したくない場合、サーバーは tables_priv と columns_priv テーブルの内容を確認する必要はまったくありません。同じように、どのアカウントにもリソース制限を設けない場合、サーバーは性能リソースカカウンティングを行う必要がありません。大量の処理が必要なときは、GRANT を使用しないことで時間を節約できる場合もあります。

明示的な MySQL 関数に関わる問題がある場合は、常に mysql クライアントで BENCHMARK() 関数の計時を行うことができます。その構文は BENCHMARK(loop_count,表現)。返される値は常に 0 ですが、mysql はステートメントの実行にどの程度の時間を要したかを表示するラインをプリントします。例 : 

mysql> SELECT BENCHMARK(1000000,1+1);
+------------------------+
| BENCHMARK(1000000,1+1) |
+------------------------+
|                      0 |
+------------------------+
1 row in set (0.32 sec)

これは Pentium II 400MHz システムで得られた結果です。この結果は、MySQL がそのシステムで 1,000,000 件の単純な加算式を 0.32 秒間で実行できることを示しています。

MySQL 関数はすべて最適化されていますが、例外も若干あります。BENCHMARK() はクエリーに関数上の問題があるかどうかを調べる際に最適のツールです。