2012-01-08 2 views
0

非常に大きなデータベース(多くのエンティティ/テーブルを意味する)にクエリを送信しています。 私は、7〜8個の結合を含むクエリをいくつか持っています。 問題は、私にはわからないが、近いうちにテーブルが持つエントリ数。これは、各テーブル(またはそれ以上)の1.000〜100.000行の間である可能性があります。最高のパフォーマンスをもたらすmysqlジョインの数は、どのように測定できますか?

1つのメガクエリの代わりに2つまたは3つのクエリを連続して実行するようにクエリを分割することを考えます。

JOINの共通/推奨制限はMySQLのクエリにありますか? テーブルの行数などに応じて、どのようなタイプの分割が適しているかを測定/計算するにはどうすればよいですか?

同じテーブルの同じフィールド(外部キー)に多くのJOINがあります。それを最適化する方法はありますか? (そのテーブルの1行 - 多くの関係/コネクションを持っている)

感謝;)

UPDATE:

私は遅すぎるそれを見ました。誰かがとても素敵で、質問のタイトルを変更しました。 私の悪い英語のために私はperformantを書いた - 良いパフォーマンスを意味する。私は実行するためにを意味しなかった! あなたの答えでこれを考慮してください。もう一度ありがとう!

答えて

2

おそらく、あなたのクエリを実行するためのMySQLの計画を示すEXPLAINについて知りたいでしょう。例えば

EXPLAIN SELECT foo FROM bar NATURAL JOIN baz 

は、MySQLがバーnaturalからのクエリSELECTのfooを実行する方法を教えてくれますあなたは、彼らは「場合は機会があなたのクエリを支援するデータベースにインデックスを追加するために見ることができるEXPLAINの結果からバズ

を登録しよう遅くなり、場合によってはヒントをクエリに追加することができます。あなたがそれを知るための経験を持っているなら、MySQLが別のインデックスよりも1つのインデックスを優先するように伝えます。

一般に、「分割」が実際に実行する必要があるセマンティクスを完全に変更しない限り、クエリを「分割」しようとしても何も得られません。例えばクエリが6つの無関係なものをデータベースからフェッチしており、それぞれを1つのものをフェッチする6つの別々のクエリとして書き直すと、実行に要した集計時間はおそらく別のクエリではそれほど良くない(さらに悪化する可能性があります)。

+0

私はあなたの答えが好きです。私は何らかの共通のルールを探しています。分かりますか? (私の更新を考慮してください) – helle

+0

私の答えは好きですが、あなたは受け入れられていないとマークしましたが、今では "共通のルール"を求めていますか?あなたは "共通のルール"がどのように見えるか想像してみましょうか? – tialaramex

+0

これまでに何か。私は自分の考えを言葉に入れることはできません。英語ではなく、私の言葉ではありません。だから私はあなたを受け入れます、それは私をまだ助けてくれたからです。 – helle

1

'desc(query);'を使用します。 MySQLがあなたのクエリをどのように扱うのかを理解してください。一般的に、MySQLは自分自身で行うよりも、参加と最適化を行う方が良いです。それは、それが良いことです。

これは、インデックス作成が機能しているか、拡張する必要があるかを示します。

+0

私の更新を考慮してください – helle

関連する問題