Sys.query_store_plan দিয়ে এলিমিনেশন কাজে কেন যোগদান করবেন না?

নীচে ক্যোয়ারী স্টোরের সাথে সম্মুখীন পারফরম্যান্স সমস্যার একটি সরলীকরণ:

CREATE TABLE #tears
(
    plan_id bigint NOT NULL
);

INSERT #tears (plan_id) 
VALUES (1);

SELECT
    T.plan_id
FROM #tears AS T
LEFT JOIN sys.query_store_plan AS QSP
    ON QSP.plan_id = T.plan_id;

plan_idকলামের প্রাথমিক কী হচ্ছে নথিভুক্ত করা sys.query_store_planকিন্তু সঞ্চালনের পরিকল্পনা ব্যবহার করে না বর্জন যোগদানের যেমন আশা করা যেতে হবে:

ডিএমভি থেকে কোনও বৈশিষ্ট্য অনুমান করা হচ্ছে না।
ডিএমভি প্রাথমিক কী plan_idঅস্থায়ী সারণী থেকে সারিগুলি নকল করতে পারে না
এ LEFT JOINব্যবহৃত হয়, সুতরাং কোনও সারি Tমুছে ফেলা যায় না।

হত্যা পরিকল্পনা

এটি কেন এবং এখানে যোগদানের বিলোপ পাওয়ার জন্য কী করা যেতে পারে?

— পল হোয়াইট 9
সূত্র

ডকুমেন্টেশনটি কিছুটা বিভ্রান্তিকর। ডিএমভি হ'ল একটি উপাদানহীন দৃশ্য এবং এর মতো প্রাথমিক কী নেই। অন্তর্নিহিত সংজ্ঞাগুলি কিছুটা জটিল তবে এর সরলিকৃত সংজ্ঞাটি sys.query_store_planহ'ল:

CREATE VIEW sys.query_store_plan AS
SELECT
    PPM.plan_id
    -- various other attributes
FROM sys.plan_persist_plan_merged AS PPM
LEFT JOIN sys.syspalvalues AS P
    ON P.class = 'PFT' 
    AND P.[value] = plan_forcing_type;

তদ্ব্যতীত, sys.plan_persist_plan_mergedএটিও একটি দৃশ্য, যদিও এর সংজ্ঞাটি দেখার জন্য একজনকে ডেডিকেটেড অ্যাডমিনিস্ট্রেটর সংযোগের মাধ্যমে সংযুক্ত হওয়া দরকার। আবার সরলীকৃত:

CREATE VIEW sys.plan_persist_plan_merged AS   
SELECT     
    P.plan_id as plan_id,    
    -- various other attributes
FROM sys.plan_persist_plan P 
    -- NOTE - in order to prevent potential deadlock
    -- between QDS_STATEMENT_STABILITY LOCK and index locks   
    WITH (NOLOCK) 
LEFT JOIN sys.plan_persist_plan_in_memory PM
    ON P.plan_id = PM.plan_id;

সূচকগুলি sys.plan_persist_planহল:

╔════════════════════════╦════════════════════════ ══════════════╦═════════════╗
║ সূচক_নাম ║ সূচক_ বিবরণ ║ সূচক_কিজ ║ ║
╠════════════════════════╬════════════════════════ ══════════════╬═════════════╣
║ প্ল্যান_পার্স্টিস্ট_প্ল্যান_সিডেক্স ║ গোষ্ঠীযুক্ত, অনন্য প্রাইমারিতে অবস্থিত ║ প্ল্যান_আইডি ║
║ প্ল্যান_পার্সিস্ট_প্লান_আইডিএক্সএক্স ║ প্রাইমারিতে অবিচ্ছিন্ন অবস্থিত ║ ক্যোয়ারী_আইডি (-) ║
╚════════════════════════╩════════════════════════ ══════════════╩═════════════╝

তাই plan_idঅনন্য হতে সীমাবদ্ধ sys.plan_persist_plan।

এখন, sys.plan_persist_plan_in_memoryএকটি স্ট্রিমিং টেবিল-মূল্যবান ফাংশন, কেবলমাত্র অভ্যন্তরীণ মেমরি স্ট্রাকচারগুলিতে রাখা ডেটার একটি টবুলার ভিউ উপস্থাপন করে। সেই হিসাবে এটির কোনও অনন্য বাধা নেই।

হার্টে, সম্পাদিত ক্যোয়ারী তাই সমান:

DECLARE @t1 table (plan_id integer NOT NULL);
DECLARE @t2 table (plan_id integer NOT NULL UNIQUE CLUSTERED);
DECLARE @t3 table (plan_id integer NULL);

SELECT 
    T1.plan_id
FROM @t1 AS T1 
LEFT JOIN
(
    SELECT 
        T2.plan_id
    FROM @t2 AS T2
    LEFT JOIN @t3 AS T3 
        ON T3.plan_id = T2.plan_id
) AS Q1
    ON Q1.plan_id = T1.plan_id;

... যা যোগদান নির্মূলের উত্পাদন করে না:

ইস্যুটির মূল দিকে পৌঁছে, সমস্যাটি হ'ল অভ্যন্তরীণ কোয়েরি:

DECLARE @t2 table (plan_id integer NOT NULL UNIQUE CLUSTERED);
DECLARE @t3 table (plan_id integer NULL);

SELECT 
    T2.plan_id
FROM @t2 AS T2
LEFT JOIN @t3 AS T3 
    ON T3.plan_id = T2.plan_id;

... স্পষ্টতই বাম জোড়ার ফলে সারিগুলি @t2অনুলিপি হতে পারে কারণ @t3এর কোনও স্বতন্ত্রতা বাধা নেই plan_id। সুতরাং, যোগদানটি বাদ দেওয়া যাবে না:

এটি কার্যকর করার জন্য, আমরা পরিষ্কারভাবে অপ্টিমাইজারকে বলতে পারি যে আমাদের কোনও সদৃশ plan_idমান প্রয়োজন নেই:

DECLARE @t2 table (plan_id integer NOT NULL UNIQUE CLUSTERED);
DECLARE @t3 table (plan_id integer NULL);

SELECT DISTINCT
    T2.plan_id
FROM @t2 AS T2
LEFT JOIN @t3 AS T3 
    ON T3.plan_id = T2.plan_id;

বাহিরের যোগটি @t3এখন মুছে ফেলা যায়:

আসল ক্যোয়ারিতে এটি প্রয়োগ করা:

SELECT DISTINCT
    T.plan_id
FROM #tears AS T
LEFT JOIN sys.query_store_plan AS QSP
    ON QSP.plan_id = T.plan_id;

সমানভাবে, আমরা এর GROUP BY T.plan_idপরিবর্তে যুক্ত করতে পারি DISTINCT। যাইহোক, অপ্টিমাইজার এখন plan_idনীড়যুক্ত দর্শনগুলির মাধ্যমে সমস্তভাবে গুণাবলীর বিষয়ে সঠিকভাবে যুক্তি দেখাতে পারে এবং উভয় বাহ্যিক যোগদানকে পছন্দসইভাবে বাদ দিতে পারে:

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

— পল হোয়াইট 9
সূত্র