問題タブ [join]

次の形式のような SQL クエリを使用しています。

そして、戻るのに少なくとも4分かかるため、遅すぎるか、何かがデッドロックしています. これを次のように変更するとします。

その後、正常に動作します（ただし、正しい数の列が返されません）。これをスピードアップする方法はありますか？

UPDATE : 後者のクエリの最後の 2 行を切り替えると、同じことが行われます。

更新 2: これらは実際に私が参加しているビューです。残念ながら、それらは私が制御できないデータベース上にあるため、インデックスを (簡単に) 変更することはできません。ただし、これはインデックス作成の問題であることに同意する傾向があります。私が知らないこのクエリを調整する魔法の方法がある場合に備えて、回答を受け入れる前に少し待ちます。それ以外の場合は、現在の回答のいずれかを受け入れて、やりたいことを行う別の方法を見つけようとします。これまでお世話になりました。

問題の例：

エンティティ：

• ユーザーには名前と友達のリストが含まれています（ユーザーリファレンス）
• ブログ投稿には、タイトル、コンテンツ、日付、ライター（ユーザー）が含まれています

要件：

ユーザーの友達による過去10件の投稿のタイトルとブログへのリンクを表示するページが必要です。また、古いエントリをページングし続ける機能も必要です。

SQLソリューション：

したがって、SQLランドでは、次のようになります。

私が考えることができるGAEソリューションは次のとおりです。

• ユーザーをロードし、友達のリストをループして、最新のブログ投稿をロードします。最後に、すべてのブログ投稿をマージして、最新の10個のブログエントリを見つけます
• ブログの投稿には、ライターを友達にしたすべてのユーザーのリストがあります。これは単純な読み取りを意味しますが、ブログ投稿がたくさんある友達を追加すると、クォータが過負荷になります。

これらのソリューションのどちらも拡張できるとは思いません。

他の人がこの問題にぶつかったと確信していますが、私は検索し、google ioビデオを見て、他の人のコードを読みました...私は何が欠けていますか？

これらすべての異なる結合をどのように区別するのか疑問に思っています...

JPAのフェッチ戦略は正確に何を制御しますか? 熱心と怠惰の違いを検出できません。どちらの場合も、JPA/Hibernate は自動的に多対 1 の関係に参加しません。

例: 個人の住所は 1 つです。アドレスは多くの人に属することができます。JPA アノテーション付きエンティティ クラスは次のようになります。

JPA クエリを使用する場合:

JPA/Hibernate は、Person テーブルから選択する 1 つの SQL クエリを生成し、次に各人物の個別のアドレス クエリを生成します。

これは、大きな結果セットでは非常に悪いことです。1000 人がいる場合、1001 個のクエリが生成されます (1 つは Person から、1000 は Address とは異なります)。これは、MySQL のクエリ ログを見ているのでわかります。アドレスのフェッチ タイプを熱心に設定すると、JPA/Hibernate が結合で自動的にクエリを実行することを理解していました。ただし、フェッチ タイプに関係なく、リレーションシップに対して個別のクエリが生成されます。

明示的に参加するように指示した場合にのみ、実際に参加します。

ここで何か不足していますか？多対 1 の関係を結合したままにするために、すべてのクエリを手作業でコーディングする必要があります。MySQL で Hibernate の JPA 実装を使用しています。

編集： JPAクエリに影響を与えないようです（Hibernate FAQ hereおよびhereを参照） 。FetchTypeしたがって、私の場合、参加するように明示的に指示しました。

JPA/Hibernate クエリで許可される結合数に制限はありますか?

Hibernateは自動的に join しないため、JPA/Hibernate クエリで明示的に結合を指定する必要があります。たとえば、人には住所があり、住所には州があります。次のクエリは、住所と州が完全に読み込まれた人物を取得します。

結合を追加し続けると、最終的に (12 ～ 13 個の結合を残した後)、Hibernate が無効な SQL を生成する限界に達します。

Hibernate の方言をデータベース実装の MySQL に設定しています。

Hibernate が単一のクエリで処理できる結合の数に制限はありますか?

編集 1:以下はログ ファイルにあります。

ただし、something69_2_SQL クエリには表示されません。Hibernate が SQL クエリを生成something69_2_し、結果に含まれることを期待しているようですが、そうではありません。

編集 2:未修正の Hibernate バグ HHH-3035として文書化された同様の問題

編集 3:これは文書化されたHibernate バグ HHH-3636であり、修正されていますが、まだどのリリースにも含まれていません。

編集 4:バグ修正 HHH-3636 を含む hibernate-core 3.3.2-SNAPSHOT をビルドしましたが、この問題は解決されませんでした。

編集 5:バグの動作はLEFT JOIN FETCH、ManyToMany または OneToMany の複数の関係によって引き起こされるようです。1 つが機能し、2 つまたは 3 つがバグになります。

編集 6:スタック トレースは次のとおりです。

編集 7:これらすべての結合の理由は、Hibernate が n+1 クエリを実行するのを避けるためです。 Hibernate クエリを実行するときに n+1 SQL SELECT クエリを回避するにはどうすればよいですか?

基本的に、次のようなmysqlクエリがあります。

そして、投稿テーブルからタイトルを取得し、投票テーブルから現在の投票値を取得する必要があります。

現時点では、投票が行われない限り、投票は投票テーブルに保存されません。したがって、投票数が 0 のすべての投稿は投票テーブルに含まれていません。

これにより、投稿 ID = 投票値 ID であるタイトルと投票値を取得しようとしているというエラーが発生します。投票テーブルにレコードがない場合、値は NULL または 0 として返されるはずですが、現時点ではクエリ全体が null として返されるため、タイトルを返すことさえできません。

これをすべて1つのクエリで修正するにはどうすればよいですか? 複数のクエリを使用する必要はありません...ありがとう:)

モデルのインスタンスを別のモデル (つまり、Task1 > Relationship < Task2) を介して同じモデルの別のインスタンスにリンクするアプリがあり、これに has_many :through を使用できるかどうか疑問に思っています。

基本的に、リレーションシップ モデルには追加情報 (type_of_relationship、lag) が含まれるため、結合モデルとして持つことが理想的です。ただし、結合するモデルは 2 つではなく、1 つだけです。has_many :through はまだ機能しますか? その場合、結合テーブルはどのようになりますか? Rails の規則では、Activity_id という 2 つの列があり、これは明らかにデータベースでは機能しません。

あるいは、has_many_and_belongs_to を使用して Task モデルと Relationship モデルの間に多対多を設定することもできますが、これが 1 つの Relationship モデルで 2 つの Task モデルのみをリンクする関係を正確に表しているかどうかはわかりません (もちろん、タスクは複数のリレーションシップに属している可能性があるため、多対多)。

私の本能は、has_many_and_belongs_to を使用してモデルのルールを整理するように言っていますが、これを行うためのより良い方法はありますか? 私はこれでぐるぐる回ります！

どんな助けでも感謝します。

私は多少経験のある Rails 開発者で、MVC の ASP.NET バージョンを試してみようと思いました。そうすることで、Linq->Sql... も試してみることにしました。

Linq->Sql が結合を処理する方法について少し混乱しています。

私のスキーマの簡単な例は次のとおりです。

書籍:
id
タイトル

カテゴリ:
ID
名前

books_categories :
book_id
カテゴリID

これらのテーブルを .dbml ファイルにドラッグするだけでは、うまくいかないようです。Book クラスの books_categories でプロパティを取得します。期待するのは、繰り返し処理して Category クラスを直接取得できるプロパティです。

今、私は非常に間違っていると感じる何かをしなければなりません

【採用された回答に対して】
「グルーコードを自分で書いてください」という回答をしぶしぶ受け入れました。Linq->Sql の調査を続けた後、(より強力な IMO) Entity Framework を支持して、Linq->Sql が明らかにゆっくりと手放されていることを発見しました。EF ではクエリに LINQ を使用することができ、Ruby の ActiveRecord のような関係を適切に把握できます。