অপারেটরের অনুমানের উন্নতি করতে ক্যোয়ারী পরিবর্তন করুন

Question

আমার কাছে একটি ক্যোয়ারী রয়েছে যা গ্রহণযোগ্য পরিমাণে চলে তবে আমি এটি থেকে সর্বাধিক পারফরম্যান্সকে গ্রাস করতে চাই।

আমি যে অপারেশনটি উন্নত করার চেষ্টা করছি তা হ'ল নোড 17 থেকে পরিকল্পনার ডানদিকে "সূচক সিক"।

আমি যথাযথ সূচকগুলি যুক্ত করেছি তবে সেই অপারেশনের জন্য আমি যে অনুমান পেয়েছি তা তাদের অনুমানের চেয়ে অর্ধেক।

আমি আমার সূচিগুলি পরিবর্তন করার জন্য এবং একটি অস্থায়ী টেবিল যুক্ত করে আবারো কোয়েরিটি লিখতে চেয়েছি, তবে সঠিক অনুমানের জন্য আমি এর চেয়ে এটিকে আরও সহজ করতে পারি না।

আমি কী আরও চেষ্টা করতে পারি সে সম্পর্কে কারও কি কোনও পরামর্শ আছে?

সম্পূর্ণ পরিকল্পনা এবং এর বিশদ এখানে পাওয়া যাবে ।

অজ্ঞাতনামা পরিকল্পনাটি এখানে পাওয়া যাবে।

হালনাগাদ:

আমার মনে হচ্ছে প্রশ্নের প্রাথমিক সংস্করণটি অনেক বিভ্রান্তি উত্থাপন করেছে, তাই আমি কিছু ব্যাখ্যা দিয়ে আসল কোডটি যুক্ত করতে যাচ্ছি।

create procedure [dbo].[someProcedure] @asType int, @customAttrValIds idlist readonly
as
begin
    set nocount on;

    declare @dist_ca_id int;

    select *
    into #temp
    from @customAttrValIds
        where id is not null;

    select @dist_ca_id = count(distinct CustomAttrID) 
    from CustomAttributeValues c
        inner join #temp a on c.Id = a.id;

    select a.Id
        , a.AssortmentId 
    from Assortments a
        inner join AssortmentCustomAttributeValues acav
            on a.Id = acav.Assortment_Id
        inner join CustomAttributeValues cav 
            on cav.Id = acav.CustomAttributeValue_Id
    where a.AssortmentType = @asType
        and acav.CustomAttributeValue_Id in (select id from #temp)
    group by a.AssortmentId
        , a.Id
    having count(distinct cav.CustomAttrID) = @dist_ca_id
    option(recompile);

end

উত্তর:

1. পেস্ট দ্য প্ল্যান লিঙ্কটিতে বিজোড় প্রাথমিক নামকরণ কেন?

   উত্তর : কারণ আমি এসকিউএল সেন্ট্রি প্ল্যান এক্সপ্লোরার থেকে বেনামে পরিকল্পনা ব্যবহার করেছি।

2. কেন OPTION RECOMPILE?

   উত্তর : কারণ আমি প্যারামিটার স্নিফিং এড়ানোর জন্য পুনরায় সংস্থাগুলি বহন করতে পারি (ডেটাটি স্কিউ করা যায় / হতে পারে)। আমি পরীক্ষা করেছি এবং অপটিমাইজার ব্যবহারের সময় যে পরিকল্পনাটি উত্পন্ন করে তাতে আমি সন্তুষ্ট OPTION RECOMPILE।

3. WITH SCHEMABINDING?

   উত্তর : আমি সত্যিই তা এড়াতে চাই এবং আমি কেবল তখনই ব্যবহার করব যখন আমার সূচী দৃষ্টিভঙ্গি হয়। যাইহোক, এটি একটি সিস্টেম ফাংশন ( COUNT()) তাই এখানের জন্য কোনও ব্যবহার SCHEMABINDINGনেই।

আরও সম্ভাব্য প্রশ্নের উত্তর:

1. আমি কেন ব্যবহার করব INSERT INTO #temp FROM @customAttrributeValues?

   উত্তর : যেহেতু আমি লক্ষ্য করেছি এবং এখন জানি যে, যখন ভেরিয়েবল ব্যবহার করে একটি ক্যোয়ারী মধ্যে প্লাগ, কোনো অনুমান করে একটি পরিবর্তনশীল সঙ্গে কাজ বাইরে আসতে সর্বদা 1. এবং আমি একটি টেম্প টেবিলের মধ্যে তথ্য দেওয়া পরীক্ষা আনুমানিক তাহলে সঙ্গে সমান প্রকৃত সারি ।

2. কেন আমি ব্যবহার করেছি and acav.CustomAttributeValue_Id in (select id from #temp) ?

   উত্তর : আমি এটি # টেম্পে একটি জয়েন্টের সাথে প্রতিস্থাপন করতে পারতাম, তবে বিকাশকারীরা খুব বিভ্রান্ত হয়েছিলেন এবং INবিকল্পটি লাভ করেছিলেন। আমি সত্যিই ভাবি না যে প্রতিস্থাপন করে এবং উভয় উপায়েই কোনও পার্থক্য থাকবে, এটি নিয়ে কোনও সমস্যা নেই।

Comments

আমি অনুমান করব যে #tempসৃষ্টি এবং ব্যবহার কার্যকারিতার জন্য সমস্যা হবে, লাভ নয়। আপনি কেবলমাত্র একবার ব্যবহার করার জন্য একটি আনডেক্সড টেবিলটিতে সঞ্চয় করছেন। এটি সম্পূর্ণরূপে অপসারণ করার চেষ্টা করুন (এবং সম্ভবত এটি in (select id from #temp)একটি existsউপশাস্ত্রে পরিবর্তন করুন

— ypercubeᵀᴹ

@ ইয়পারক्यूब ᵀᴹ সত্য, একটি টেম্প টেবিলের পরিবর্তে ভেরিয়েবলটি ব্যবহার করে কেবলমাত্র কয়েকটি কম পৃষ্ঠা পড়ে read

— রাদু ঘিওরঘিউ

উপায় দ্বারা, একটি সারণী ভেরিয়েবল অপশন (পুনঃনির্মাণ) এর সাথে ব্যবহার করার সময় সঠিক সারি গণনা অনুমান সরবরাহ করবে - তবে এখনও গ্রানুলার পরিসংখ্যান, কার্ডিনালিটি ইত্যাদি নেই

— TH

@ তম ভাল, select id from @customAttrValIdsপরিবর্তে ব্যবহার করার সময় আমি অনুমানগুলিতে প্রকৃত বাস্তবায়ন পরিকল্পনাটি দেখেছিলাম এবং select id from #tempসারিগুলির আনুমানিক সংখ্যাটি 1ভেরিয়েবল এবং 3# টিম্পের জন্য ছিল (যা সারিগুলির আসল # টির সাথে মিলেছে)। এজন্য আমি প্রতিস্থাপন @করেছি #। এবং আমি DO যেখানে তারা বলেন যে যখন একটি tbl পরিবর্তনশীল ব্যবহার যে জন্য অনুমান সবসময় 1. করা হবে এবং একটি উন্নতি যেমন ভাল অনুমান তারা একটি অস্থায়ী টেবিল ব্যবহার করেন পেতে (ব্রেন্ট O অথবা হারুন বারট্রান্ড থেকে) একটি টক মনে রাখবেন।

— রাদু ঘিওরঘিউ

@ রাদুঘিওরঘিউ হ্যাঁ তবে সেই ছেলেদের বিশ্বে বিকল্প (পুনঃসংযোগ) খুব কমই একটি বিকল্প এবং এগুলি অন্যান্য বৈধ কারণে অস্থায়ী টেবিলগুলিও পছন্দ করে। : হয়তো অনুমান কেবল সবসময় ভুল 1 শো, যেমন এখানে দেখা যেমন পরিকল্পনা পরিবর্তন করেন theboreddba.com/Categories/FunWithFlags/...

— টি এইচ

Answer 1

পরিকল্পনাটি একটি এসকিউএল সার্ভার ২০০৮ আর 2 আরটিএম ইনস্ট্যান্সে তৈরি করা হয়েছিল (10.50.1600 বিল্ড করুন)। আপনার ইনস্টল করা উচিত সার্ভিস প্যাক 3 (10.50.6000 তৈরি করুন) এবং সর্বশেষতম প্যাচগুলি এটি (বর্তমান) সর্বশেষতম বিল্ড 10.50.6542 এ আনতে হবে followed সুরক্ষা, বাগ সংশোধন এবং নতুন বৈশিষ্ট্য সহ বিভিন্ন কারণে এটি গুরুত্বপূর্ণ।

প্যারামিটার এম্বেডিং অপটিমাইজেশন

বর্তমান প্রশ্নের সাথে সম্পর্কিত, এসকিউএল সার্ভার ২০০৮ আর 2 আরটিএম এর জন্য প্যারামিটার এম্বেডিং অপ্টিমাইজেশন (পিইও) সমর্থন করে না OPTION (RECOMPILE) । এই মুহুর্তে, আপনি মূল সুবিধাগুলির মধ্যে একটি অনুধাবন না করে পুনঃনির্মাণের মূল্য প্রদান করছেন।

যখন পিইও উপলব্ধ থাকে, এসকিউএল সার্ভার স্থানীয় ভেরিয়েবল এবং প্যারামিটারগুলিতে সংরক্ষিত আক্ষরিক মানগুলি সরাসরি ক্যোয়ারী পরিকল্পনায় ব্যবহার করতে পারে। এটি নাটকীয় সরলীকরণ এবং পারফরম্যান্স বৃদ্ধি হতে পারে। আমার নিবন্ধে সে সম্পর্কে আরও তথ্য রয়েছে, প্যারামিটার স্নিফিং, এম্বেডিং এবং পুনঃসংযোগ বিকল্পগুলি ।

হ্যাশ, বাছাই এবং এক্সচেঞ্জ স্পিলস

এসকিউএল সার্ভার ২০১২ বা তারপরে কোয়েরিটি সংকলিত হয়েছিল তখন এগুলি কেবল কার্যকরকরণ পরিকল্পনাগুলিতে প্রদর্শিত হয়। পূর্ববর্তী সংস্করণগুলিতে, ক্যোয়ারী প্রোফাইলার বা বর্ধিত ইভেন্টগুলি ব্যবহার করে চালিত হওয়ার সময় আমাদের স্পিলের জন্য নজরদারি করতে হয়েছিল। স্পিল সবসময় শারীরিক I / O থেকে (এবং থেকে) অবিচ্ছিন্ন স্টোরেজ ব্যাকিং টেম্পডিবিতে আসে ফলাফল দেয়, যার কার্যকর কার্যকারিতা হতে পারে, বিশেষত যদি বড় হয়, বা I / O পাথ চাপে থাকে।

আপনার এক্সিকিউশন প্ল্যানে, দুটি হ্যাশ ম্যাচ (সমষ্টি) অপারেটর রয়েছে। হ্যাশ টেবিলের জন্য সংরক্ষিত মেমরিটি আউটপুট সারিগুলির অনুমানের উপর ভিত্তি করে (অন্য কথায়, এটি রানটাইমের সময় পাওয়া গ্রুপগুলির সংখ্যার সাথে আনুপাতিক)। প্রদত্ত মেমরিটি কার্যকর হওয়া শুরু হওয়ার ঠিক আগে স্থির করা হয় এবং কার্যকরকরণের সময় উদাহরণস্বরূপ কতটা মুক্ত মেমরি থাকে তা নির্বিশেষে বাড়তে পারে না। সরবরাহিত পরিকল্পনায়, উভয় হ্যাশ ম্যাচ (সমষ্টি) অপারেটরগুলি অপটিমাইজারের প্রত্যাশার চেয়ে বেশি সারি তৈরি করে এবং তাই রানটাইমটিতে টেম্পডবি করার জন্য একটি প্রস্রাবের সম্মুখীন হতে পারে ।

পরিকল্পনায় একটি হ্যাশ ম্যাচ (ইনার জয়েন) অপারেটরও রয়েছে। হ্যাশ টেবিলের জন্য সংরক্ষিত মেমরিটি প্রোব পার্শ্ব ইনপুট সারিগুলির অনুমানের ভিত্তিতে । অনুসন্ধানের ইনপুটটি 847,399 টি সারি অনুমান করে, তবে 1,223,636 রান সময়টিতে সম্মুখীন হয়। এই অতিরিক্তটি হ্যাশ ছড়িয়ে পড়ার কারণ হতে পারে।

অপ্রয়োজনীয় সমষ্টি

নোড 8-এ হ্যাশ ম্যাচ (সমষ্টি) একটি গ্রুপিং ক্রিয়াকলাপ সম্পাদন করে (Assortment_Id, CustomAttrID)তবে ইনপুট সারিগুলি আউটপুট সারিগুলির সমান:

এটি কলাম সংমিশ্রণটি একটি কী (তাই গোষ্ঠীকরণটি শব্দার্থগতভাবে অপ্রয়োজনীয়) পরামর্শ দেয়। অপ্রয়োজনীয় সমষ্টি সম্পাদনের ব্যয় হ্যাশ পার্টিশনিং এক্সচেঞ্জগুলিতে দুইবার 1.4 মিলিয়ন সারি পাস করার প্রয়োজনীয়তা দ্বারা বৃদ্ধি করা হয়েছে (উভয় পক্ষের সমান্তরালতা অপারেটর)।

জবাব দেওয়া কলামগুলি বিভিন্ন টেবিল থেকে আসে, এই স্বতন্ত্রতা তথ্যটি অপ্টিমাইজারের সাথে যোগাযোগ করা স্বাভাবিকের চেয়ে বেশি কঠিন, তাই এটি অপ্রয়োজনীয় গ্রুপিং অপারেশন এবং অপ্রয়োজনীয় এক্সচেঞ্জগুলি এড়াতে পারে।

অপর্যাপ্ত থ্রেড বিতরণ

জো ওবিশের উত্তরে উল্লিখিত হিসাবে , নোড 14 এ এক্সচেঞ্জ থ্রেডগুলির মধ্যে সারি বিতরণ করতে হ্যাশ বিভাজন ব্যবহার করে। দুর্ভাগ্যক্রমে, সংখ্যার কম সংখ্যক সারি এবং উপলব্ধ সিডিউলারের অর্থ তিনটি সারি একক থ্রেডে শেষ। আপাতদৃষ্টিতে সমান্তরাল পরিকল্পনাটি ক্রমিকভাবে (সমান্তরাল ওভারহেড সহ) নোড 9 এ এক্সচেঞ্জের অবধি চলে।

নোড 13 এ ডিসট্রিন্ট সাজান্ট কেটে আপনি এটিকে (রাউন্ড-রবিন বা ব্রডকাস্ট পার্টিশন অর্জনের জন্য) সম্বোধন করতে পারেন that এটি করার সহজতম উপায় হ'ল #tempটেবিলে একটি ক্লাস্টার্ড প্রাথমিক কী তৈরি করা এবং টেবিলটি লোড করার সময় স্বতন্ত্র ক্রিয়াকলাপ সম্পাদন করা:

CREATE TABLE #Temp
(
    id integer NOT NULL PRIMARY KEY CLUSTERED
);

INSERT #Temp
(
    id
)
SELECT DISTINCT
    CAV.id
FROM @customAttrValIds AS CAV
WHERE
    CAV.id IS NOT NULL;

অস্থায়ী টেবিলের পরিসংখ্যান ক্যাশে

ব্যবহার সত্ত্বেও OPTION (RECOMPILE), এসকিউএল সার্ভার এখনও অস্থায়ী টেবিল অবজেক্ট এবং প্রক্রিয়া কলগুলির মধ্যে সম্পর্কিত সম্পর্কিত পরিসংখ্যানকে ক্যাশে করতে পারে । এটি সাধারণত একটি স্বাগত কর্মক্ষমতা অপ্টিমাইজেশন, তবে অস্থায়ী টেবিলটি সংলগ্ন প্রক্রিয়া কলগুলিতে একই পরিমাণের ডেটা দ্বারা পপুলেশন করা থাকলে পুনরায় সংযুক্ত পরিকল্পনাটি ভুল পরিসংখ্যানের উপর ভিত্তি করে তৈরি হতে পারে (একটি পূর্ববর্তী মৃত্যুদন্ড কার্যকর করা)) এটি আমার নিবন্ধগুলিতে বিশদভাবে রয়েছে, সঞ্চিত পদ্ধতিতে অস্থায়ী টেবিলগুলি এবং অস্থায়ী টেবিল ক্যাশে ব্যাখ্যা করা হয় ।

এটি এড়াতে অস্থায়ী টেবিলটি জনপ্রিয় হওয়ার পরে এবং এটি কোনও ক্যোরিতে রেফারেন্স দেওয়ার আগে OPTION (RECOMPILE)একটি স্পষ্ট সঙ্গে একসাথে ব্যবহার করুন UPDATE STATISTICS #TempTable।

পুনরায় লেখার প্রশ্ন

এই অংশটি ধরে নিয়েছে যে #Tempটেবিল তৈরির পরিবর্তনগুলি ইতিমধ্যে করা হয়েছে।

সম্ভাব্য হ্যাশ স্পিলের ব্যয় এবং অতিরিক্ত কাজ (এবং আশেপাশের এক্সচেঞ্জ) দেওয়া, এটি নোড 10 এ সেটটি বাস্তবায়নের জন্য অর্থ দিতে পারে:

CREATE TABLE #Temp2
(
    CustomAttrID integer NOT NULL,
    Assortment_Id integer NOT NULL,
);

INSERT #Temp2
(
    Assortment_Id,
    CustomAttrID
)
SELECT
    ACAV.Assortment_Id,
    CAV.CustomAttrID
FROM #temp AS T
JOIN dbo.CustomAttributeValues AS CAV
    ON CAV.Id = T.id
JOIN dbo.AssortmentCustomAttributeValues AS ACAV
    ON T.id = ACAV.CustomAttributeValue_Id;

ALTER TABLE #Temp2
ADD CONSTRAINT PK_#Temp2_Assortment_Id_CustomAttrID
PRIMARY KEY CLUSTERED (Assortment_Id, CustomAttrID);

PRIMARY KEYএকটি পৃথক ধাপে যোগ করা হয় সূচক বিল্ড নিশ্চিত করার সঠিক cardinality তথ্য হয়েছে, এবং ইস্যু ক্যাশে অস্থায়ী টেবিল পরিসংখ্যান এড়ানো।

উদাহরণস্বরূপ পর্যাপ্ত মেমরি উপলব্ধ থাকলে এই ধাতবকরণ মেমরির ( টেম্পিডবি আই / ও এড়িয়ে চলা ) হওয়ার সম্ভাবনা রয়েছে। আপনি এসকিউএল সার্ভার ২০১২ (এসপি 1 সিই 10 / এসপি 2 সিই 1 বা তারপরে) আপগ্রেড হওয়ার পরে এটি আরও বেশি সম্ভাবনা রয়েছে যা এগার লেখার আচরণকে উন্নত করেছে ।

এই ক্রিয়াটি মধ্যবর্তী সেটে অনুকূলকরণের সঠিক কার্ডিনালিটির তথ্য দেয়, এটি পরিসংখ্যান তৈরি করতে দেয় এবং আমাদের (Assortment_Id, CustomAttrID)কী হিসাবে ঘোষণা করতে দেয় ।

জনসংখ্যার পরিকল্পনাগুলি #Temp2দেখতে এইরকম হওয়া উচিত (ক্লাস্টারড ইনডেক্স স্ক্যানটি নোট করুন #Temp, কোনও বিচ্ছিন্ন বাছাই করা নেই, এবং এক্সচেঞ্জটি এখন রাউন্ড-রবিন সারি পার্টিশন ব্যবহার করে):

এই সেটটি উপলভ্য হওয়ার সাথে সাথে চূড়ান্ত ক্যোয়ারীটি হয়ে যায়:

SELECT
    A.Id,
    A.AssortmentId
FROM
(
    SELECT
        T.Assortment_Id
    FROM #Temp2 AS T
    GROUP BY
        T.Assortment_Id
    HAVING
        COUNT_BIG(DISTINCT T.CustomAttrID) = @dist_ca_id
) AS DT
JOIN dbo.Assortments AS A
    ON A.Id = DT.Assortment_Id
WHERE
    A.AssortmentType = @asType
OPTION (RECOMPILE);

আমরা ম্যানুয়ালি COUNT_BIG(DISTINCT...এটিকে একটি সাধারণ হিসাবে পুনরায় লিখতে পারি COUNT_BIG(*), তবে নতুন কী তথ্য সহ, অপ্টিমাইজারটি আমাদের জন্য এটি করে:

চূড়ান্ত পরিকল্পনাটি আমার কাছে অ্যাক্সেস নেই এমন ডেটা সম্পর্কিত পরিসংখ্যান সম্পর্কিত তথ্যের উপর নির্ভর করে একটি লুপ / ​​হ্যাশ / মার্জ জোড় ব্যবহার করতে পারে। অন্য একটি ছোট নোট: আমি ধরে নিয়েছি যে এর মতো একটি সূচকও CREATE [UNIQUE?] NONCLUSTERED INDEX IX_ ON dbo.Assortments (AssortmentType, Id, AssortmentId);বিদ্যমান।

যাইহোক, চূড়ান্ত পরিকল্পনাগুলি সম্পর্কে গুরুত্বপূর্ণ বিষয়টি হল অনুমানগুলি আরও ভাল হওয়া উচিত এবং গ্রুপিং ক্রিয়াকলাপগুলির জটিল ক্রমটি একটি একক স্ট্রিম এগ্রিগ্রেটে হ্রাস করা হয়েছে (যার জন্য মেমরির প্রয়োজন হয় না এবং তাই ডিস্কে ছড়িয়ে দিতে পারে না)।

এটি বলা শক্ত যে অতিরিক্ত অস্থায়ী টেবিলের সাথে এই ক্ষেত্রে পারফরম্যান্স আসলে আরও ভাল হবে , তবে সময়ের সাথে সাথে ডেটা ভলিউম এবং বিতরণে পরিবর্তনের জন্য অনুমানগুলি এবং পরিকল্পনার পছন্দগুলি আরও বেশি স্থিতিস্থাপক হবে। এটি আজ একটি ছোট পারফরম্যান্স বৃদ্ধির চেয়ে দীর্ঘমেয়াদে আরও মূল্যবান হতে পারে। যাই হোক না কেন, আপনার চূড়ান্ত সিদ্ধান্তটি কোনটি ভিত্তিতে ভিত্তি করে তা এখন আপনার কাছে আরও অনেক তথ্য রয়েছে।

Answer 2

আপনার ক্যোয়ারিতে কার্ডিনালিটির অনুমানগুলি আসলে খুব ভাল। প্রকৃত সারিগুলির সংখ্যার সাথে হুবহু মিলের জন্য আনুমানিক সারিগুলির সংখ্যা পাওয়া বিরল, বিশেষত যখন আপনি এই অনেকগুলিতে যোগদান করেন। অপ্টিমাইজারটি সঠিক হয়ে উঠার জন্য কার্ডিনালিটির আনুমানিক যোগ দিনগুলি জটিল। একটি গুরুত্বপূর্ণ বিষয় লক্ষণীয় যে নেস্টেড লুপের অভ্যন্তরীণ অংশের জন্য আনুমানিক সারিগুলির সংখ্যা সেই লুপটির সম্পাদন হিসাবে। সুতরাং যখন এসকিউএল সার্ভার বলছে যে সূচকটি নিয়ে 463869 সারিগুলি পাওয়া যাবে তবে এক্ষেত্রে ফাঁসির সংখ্যা (2) * 463869 = 927738 যা সারিগুলির প্রকৃত সংখ্যা, 1391608 থেকে খুব বেশি দূরে নয়। অবাক করার বিষয়, নোড আইডি 10 এ নেস্টেড লুপে যোগদানের পরপরই আনুমানিক সারিগুলির সংখ্যা নিখুঁত।

যখন ক্যোয়ারী অপ্টিমাইজার ভুল পরিকল্পনাটি গ্রহণ করে বা পরিকল্পনার জন্য পর্যাপ্ত মেমরি দেয় না তখন দরিদ্র কার্ডিনালিটির অনুমানগুলি বেশিরভাগই একটি সমস্যা। আমি এই পরিকল্পনার জন্য টেম্পডবি করার জন্য কোনও স্পিল দেখতে পাচ্ছি না, তাই স্মৃতিটি ঠিক আছে looks নেস্টেড লুপের সাথে যুক্ত হওয়ার জন্য যা আপনি ডেকেছেন আপনার কাছে একটি ছোট বাইরের টেবিল এবং একটি সূচিযুক্ত অভ্যন্তর টেবিল রয়েছে। তাতে কী দোষ? সুনির্দিষ্টভাবে বলতে গেলে, আপনি কোয়েরি অপ্টিমাইজারটি এখানে অন্যভাবে কী করবে বলে আশা করবেন?

পারফরম্যান্স উন্নয়নের ক্ষেত্রে, আমার কাছে যে বিষয়টি দাঁড়িয়েছে তা হ'ল এসকিউএল সার্ভার সমান্তরাল সারিগুলি বিতরণ করতে একটি হ্যাশিং অ্যালগরিদম ব্যবহার করছে যার ফলস্বরূপ তাদের সমস্ত একই থ্রেডে রয়েছে:

ফলস্বরূপ, একটি থ্রেড সূচকের সন্ধানের সাথে সমস্ত কাজ করে:

এর অর্থ হল যে আপনার ক্যোয়ারি কার্যকরভাবে সমান্তরালভাবে চলবে না যতক্ষণ না নোড আইডিতে পুনরায় বিভাজন প্রবাহ অপারেটর করে round এটি সূচকটি নোড আইডি 17-এর জন্য অনুসন্ধান করতে দুটি থ্রেডকে মঞ্জুরি দেবে। একটি অতিরিক্ত অতিরিক্ত TOPঅপারেটর যুক্ত করা আপনাকে রাউন্ড রবিন বিভাজন পেতে পারে। আপনি চাইলে আমি এখানে বিশদ যুক্ত করতে পারি।

আপনি যদি সত্যিকারের কার্ডিনালিটির অনুমানগুলিতে ফোকাস করতে চান তবে আপনি প্রথম টেম্প টেবিলে যোগদানের পরে সারিগুলিকে রাখতে পারেন। যদি আপনি টেম্প টেবিলের পরিসংখ্যানগুলি সংগ্রহ করেন যা নেস্টেড লুপের জন্য বাহিরের টেবিল সম্পর্কে অপ্টিমাইজারটিকে আরও তথ্য দেয় যা আপনি কল করেছিলেন। এটির ফলে রাউন্ড রবিন বিভাজন হতে পারে।

আপনি যদি ট্রেস ফ্ল্যাগগুলি 4199 বা 2301 ব্যবহার না করেন তবে আপনি সেগুলি বিবেচনা করতে পারেন। ট্রেস পতাকা 4199 বিভিন্ন ধরণের অপটিমাইজার সংশোধন করে, তবে তারা কিছু কাজের চাপকে হ্রাস করতে পারে। ট্রেস পতাকা 2301 ক্যোয়ারী অপ্টিমাইজারের কিছু যোগদানের কার্ডিনালিটি অনুমানগুলিকে পরিবর্তন করে এবং আরও কঠোর করে তোলে। উভয় ক্ষেত্রে এগুলি সক্ষম করার আগে সাবধানতার সাথে পরীক্ষা করুন।

Answer 3

আমি বিশ্বাস করি যে যোগদানের চেয়ে আরও ভাল অনুমান পাওয়া পরিকল্পনার কোনও পরিবর্তন ঘটবে না, যদি না 1.4 মিলটি টেবিলের পর্যাপ্ত অংশ না হয় তবে অপটিমাইজারকে হ্যাশ দিয়ে স্ক্রিন (ক্লাস্টার নয়) স্ক্যান বাছাই করে তুলতে সক্ষম করে তোলে join আমি সন্দেহ করি যে এখানে কেস হবে না, তবে আসলেই সহায়ক হবে না তবে আপনি কাস্টমঅ্যাট্রিবিউটভ্যালিয়ুসের অভ্যন্তরীণ হ্যাশ জয়েন এবং অভ্যন্তরীণ সংশ্লেষের যোগ দিয়ে অভ্যন্তরীণ যোগদানের পরিবর্তে প্রভাবগুলি পরীক্ষা করতে পারেন ।

আমি কোডটি আরও বিস্তৃতভাবে দেখেছি এবং এর উন্নতির কোনও উপায় দেখতে পাচ্ছি না - আমি অবশ্যই ভুল প্রমাণিত হতে আগ্রহী হতে চাই। এবং আপনি যদি অর্জন করার চেষ্টা করছেন তার সম্পূর্ণ যুক্তি পোস্ট করার মতো মনে হয় তবে আমি অন্য চেহারাতে আগ্রহী হব।

Comments

এই ক্যোয়ারির জন্য পরিকল্পনাগুলির একটি খুব বিশাল স্থান রয়েছে, যোগ দেওয়ার অর্ডার এবং নেস্টিং, সমান্তরালতা, স্থানীয় / বৈশ্বিক সমষ্টি ইত্যাদি ইত্যাদির অনেক বিকল্প রয়েছে যার বেশিরভাগই প্রাপ্ত সংখ্যার পরিবর্তনের দ্বারা প্রভাবিত হবে (বিতরণ পাশাপাশি কাঁচা কার্ডিনালিটি) প্ল্যান নোডে ১০. এছাড়াও নোট করুন যে যোগদানের ইঙ্গিতগুলি সাধারণত এড়িয়ে চলা উচিত যেহেতু তারা একটি নীরব সাথে আসে OPTION(FORCE ORDER), যা অপ্টিমাইজারটিকে পুনরায় সাজানোকে পাঠ্যক্রমিক ক্রম থেকে যোগ দেয় এবং আরও অনেক অপ্টিমাইজেশানকে বাধা দেয়।

— পল হোয়াইট 9

Answer 4

আপনি কোনও [ক্লাস্টারবিহীন] সূচি সন্ধান থেকে উন্নতি করতে যাচ্ছেন না। একটি ক্লাস্টারযুক্ত সূচকের চেয়ে ভাল জিনিসটি একটি ক্লাস্টারড ইনডেক্স সিক।

এছাড়াও, আমি গত দশ বছর ধরে একটি এসকিউএল ডিবিএ এবং এর আগে পাঁচ বছরের জন্য এসকিউএল বিকাশকারী হয়েছি এবং আমার অভিজ্ঞতা হিসাবে আপনি যে এক্সিকিউশন প্ল্যানটি করতে পারেননি তা অধ্যয়ন করে একটি এসকিউএল ক্যোয়ারির উন্নতি খুঁজে পাওয়া অত্যন্ত বিরল is অন্য উপায়ে খুঁজে না। এক্সিকিউশন প্ল্যান উত্পন্ন করার মূল কারণ হ'ল এটি প্রায়শই আপনাকে অনুপস্থিত সূচীগুলির প্রস্তাব দেয় যা আপনি কর্মক্ষমতা উন্নত করতে যোগ করতে পারেন।

মূল কার্যকারিতা লাভগুলি এসকিউএল ক্যোয়ারী নিজেই সামঞ্জস্য করতে হবে, যদি সেখানে কোনও অদক্ষতা থাকে। উদাহরণস্বরূপ, কয়েক মাস আগে আমি SELECT UNION SELECTস্ট্যান্ডার্ড এসকিউএল PIVOTঅপারেটরটি ব্যবহার করার জন্য স্টাইলের পিভট টেবিলটি পুনরায় লিখে 160 গুণ দ্রুত চালানোর জন্য এসকিউএল ফাংশন পেয়েছি ।

insert into Variable1 values (?), (?), (?)


select *
    into Object1
    from Variable2
        where Column1 is not null;



select Variable3 = Function1(distinct Column2) 
    from Object2 Object3
        inner join Object1 Object4 on Object3.Column1 = Object4.Column1;



select Object4.Column1
        , Object4.Column3 
    from Object5 Object4
        inner join Object6 Object7
            on Object4.Column1 = Object7.Column4
        inner join Object2 Object8 
            on Object8.Column1 = Object7.Column5
    where Object4.Column6 = Variable4
        and Object7.Column5 in (select Column1 from Object1)
    group by Object4.Column3
        , Object4.Column1
    having Function1(distinct Object8.Column2) = Variable3
    option(recompile);

সুতরাং আসুন দেখুন, SELECT * INTOএকটি মানের তুলনায় সাধারণত কম দক্ষ INSERT Object1 (column list) SELECT column list। সুতরাং আমি আবার লিখতে হবে। এরপরে, যদি ফাংশন 1 কে ছাড়াই সংজ্ঞায়িত করা হয় WITH SCHEMABINDING, একটি WITH SCHEMABINDINGধারা যুক্ত করার সাথে এটি দ্রুত চালনার অনুমতি দেওয়া উচিত।

আপনি অনেকগুলি উপাধি বাছাই করেছেন যা অবজেক্ট 3 হিসাবে অবজেক্ট 2কে এলিয়াসিংয়ের মতো বোঝায় না। আপনার কোডটি অস্পষ্ট করে না এমন আরও ভাল উপাধি নির্বাচন করা উচিত। আপনার কাছে "অবজেক্ট 7.কলাম 5" রয়েছে (অবজেক্ট 1 থেকে কলাম 1 নির্বাচন করুন) "।

INএই প্রকৃতির ধারাগুলি সবসময় আরও দক্ষ হিসাবে লিখিত হয় EXISTS (SELECT 1 FROM Object1 o1 WHERE o1.Column1 = Object7.Column5)। সম্ভবত আমার অন্যভাবে লেখা উচিত ছিল। EXISTSসর্বদা কমপক্ষে হিসাবে ভাল হবে IN। এটি সবসময় ভাল হয় না, তবে সাধারণত হয়।

এছাড়াও, আমি সন্দেহ করি যে option(recompile)এখানে ক্যোয়ারী পারফরম্যান্স উন্নতি করছে। আমি এটি অপসারণ পরীক্ষা হবে।

Comments

যদি একটি অবিচ্ছিন্ন সূচী অনুসন্ধান জিজ্ঞাসাটি কভার করে, এটি প্রায় সর্বদা ক্লাস্টারড সূচীর চেয়ে ভাল হতে চলেছে, কারণ সংজ্ঞা অনুসারে, ক্লাস্টারড ইনডেক্সের সমস্ত কলাম রয়েছে, এবং অবিচ্ছিন্ন সূচকের মধ্যে কম কলাম রয়েছে যাতে কম পৃষ্ঠা সিক্সের প্রয়োজন হবে (এবং বি-ট্রি-তে কয়েকটি স্তরের পদক্ষেপ) ডেটা পুনরুদ্ধার করতে। সুতরাং এটি বলা সঠিক নয় যে একটি ক্লাস্টারযুক্ত সূচক সর্বদা আরও ভাল হবে will

— এরিক