特にすべてのクエリ間の接続を閉じていない場合は、mysql クエリの接続オーバーヘッドについてあまり心配しません。クエリが一時テーブルを作成する場合、クエリのオーバーヘッドよりも多くの時間をクエリに費やしていることを考慮してください。
個人的には複雑な SQL クエリを実行するのが大好きですが、テーブルのサイズ、mysql クエリ キャッシュ、および範囲チェック (インデックスに対しても) を実行する必要があるクエリのクエリ パフォーマンスのすべてが違いを生むことがわかりました。
私はこれを提案します:
1)シンプルで正しいベースラインを確立します。これは無数のクエリのアプローチだと思います。これは間違いではなく、非常に正しい可能性が非常に高いです。数回実行して、クエリ キャッシュとアプリケーションのパフォーマンスを確認します。特に他のコード メンテナーと協力している場合は、アプリをメンテナンスしやすい状態に保つことが非常に重要です。また、非常に大きなテーブルをクエリしている場合は、小さなクエリでスケーラビリティが維持されます。
2)複雑なクエリをコーディングします。結果の精度を比較してから、時間を比較します。次に、クエリで EXPECT を使用して、スキャンされた行が何であるかを確認します。JOIN、WHERE x != y、または一時テーブルを作成する条件がある場合、特に常に更新されるテーブルにいる場合、クエリのパフォーマンスがかなり悪くなることがよくあります。ただし、複雑なクエリは正しくない可能性があり、複雑なクエリはアプリケーションが大きくなるにつれて壊れやすくなることもわかりました。複雑なクエリは通常、より大きな行セットをスキャンし、多くの場合、一時テーブルを作成してusing where
スキャンを呼び出します。テーブルが大きくなればなるほど、これらはより高価になります。また、複雑なクエリがチームの強みに合わないというチームの考慮事項がある場合もあります。
3) 結果をチームと共有します。
複雑なクエリは mysql クエリ キャッシュにヒットする可能性が低く、十分に大きい場合はキャッシュしないでください。(頻繁にヒットするクエリのために mysql クエリ キャッシュを保存する必要があります。) また、インデックスをスキャンする必要がある述語を含むクエリもうまくいきません。(x != y、x > y、x < y)。のようなクエリは、SELECT foo, bar FROM users WHERE foo != 'g' and mumble < '360'
最終的にスキャンを実行します。(その場合、クエリのオーバーヘッドのコストは無視できます。)
小規模なクエリは、選択して述語しているフィールドがインデックス化されている限り、インデックスからすべての値を取得するだけで一時テーブルを作成せずに完了することがよくあります。そのため、 のクエリ パフォーマンスSELECT foo, bar FROM users WHERE id = x
は非常に優れています (特に、列foo
とbar
が のようにインデックス付けされている場合alter table users add index ix_a ( foo, bar );
)。
アプリケーションのパフォーマンスを向上させるその他の良い方法は、これらの小さなクエリ結果をアプリケーションにキャッシュする (適切な場合) か、マテリアライズド ビュー クエリのバッチ ジョブを実行することです。また、memcached または XCache にあるいくつかの機能を検討してください。