2017-12-26 38 views
0

私は顧客のためにピラミッドスキームを設計しており、この構造をシステムに適用しようとしています。参照スキームです。誰かがウェブサイトに参加するためのイントロなら、すべての上位層が紹介料を享受します。ピラミッドループのパフォーマンスチューニング

enter image description here

これは、私のテーブル構造であるので、列で紹介に基づいて、私はすべての上の行または特定のユーザーの下の行をバック見つけることができます。

しかしループにこの文を使用してI、(申し訳ありません、それは大きいので、完全なコードを提供することはできませんが、それは以下のコードを理解することが簡単にできます)

for (int a = 0; a < lowerLine.Count; a++) 
{ 
    var query3 = from data in db.users_table where data.referral_by == referralUser && data.is_activated == true select new{ data.user_id,data.introducer}; 
    var lowerLine2 = query3.ToList(); 
    lowerLineCount2 += lowerLine2.Count; 
    totalCount += lowerLine2.Count; 
} 

それは、LINQ文のときに、それ総紹介を得るためにピラミッドの終わりまでループし続けます。しかし、もしこれを実行すると、彼は500の参照を持っていると、すべてのデータを取得するのが非常に遅くなります。

この場合、ストアドプロシージャを使用してすべてのデータを取得するソリューションがあると思いますが、そのステートメントを500回実行しようとすると、パフォーマンスはまだ非常に遅い26秒ですが、すべてのデータを取り出します。その結果、ストアドプロシージャは、一度 enter image description here

で実行したとき、それはまだ遅くなりますので、選択ではない私は、10秒以内に、このピラミッドスキームからすべてのデータを取得する方法を知っているかもしれませんか?私はchar(n)が悪い癖で、簡単にあなたの問題原因、私は常にユーザーに入力されたNVARCHAR(n)を使用したいことができます使用して、しかし、私は結果によって紹介のインデックスはまだ

+0

可能なアプローチ:[https://stackoverflow.com/a/18111876/1565525](https://stackoverflow.com/a/18111876/1565525) – Fabio

+0

またその良くありませんポストを読むのが少し難しくなるので、あまりにも多くの写真を貼り付けるには –

答えて

0

まず遅いんでした、インデックスに心をいけませんデータ。

第2にの場合、ストアドプロシージャのRecursive Common Table Expression (CTE)を調べるとよいでしょう。テーブルのサイズやその他の要因によっては、EFで照会するよりもはるかに優れたパフォーマンスが得られるでしょう。しかし、標準的なT-SQLループも同様にテストする価値があります。詳細は以下を参照してください。

最後、私は

...いずれかの方法

idは、それが適切にインデックス化されていることを確認しても、このEFコード・ファーストアプローチとあなたのreferral_byは、ナビゲーションプロパティであるかどうかわからないんだけど以下のコードは、紹介ツリーのリストを@SomeUser(つまり、元の質問ごとに新しく追加されたメンバー)のリストにしようとしています。

  • これは単なる一例であり、していない:私はあなたが最低ラインのもの

    CTE

    With UserCte as 
    (
        //Anchor Query 
        Select user_id, first_name, last_name, referral_by from users Where [email protected] 
        Union all 
        //Recursive Query 
        Select U.user_id, U.first_name, U.last_name, U.referral_by from users U 
        Inner Join UserCte M //Joining with anchor member 
        On U.user_id = M.user_id 
    ) 
    
    //Returning all user of user_id @SomeUser 
    Select * from UserCte 
    

    ノートでやろうとしているか全くわからないんだけどテストされましたが、それはより良い方向にあなたを指す必要があります

  • 誰かのために良いものは、yに良いものではないかもしれないパフォーマンスのハードと高速のルールはありません独自のシステムあなたのIndexing.Forあなたは非常によく使用することができます

リソース

Using Common Table Expressions

Optimize Recursive CTE Query

+1

これは、ユーザーが入力したデータに常にNVARCHAR(n)を使用します –

-1

で物事のこれらのタイプを使用して独自のベンチマークを行うには、OU、その最高大文字と小文字の区別がない場合は、プライマリインデックスまたはクラスタインデックスを使用できます。 これは、まず、頻繁に使用されている列とクエリがどれであるかを判断する必要があります。あなたのERモデルを何度も改訂する必要があります。パフォーマンスが向上することを願っています。

SQLテーブルを見ると、ERモデルを正しく修正していない可能性があります。テーブルには非常に多くの空の列があります。 したがって、ルートから開始し、自動的に違いが表示されます。あなたの参照のために

Indexing

関連する問題