এই জাতীয় অনুরূপ প্রশ্নগুলি কেন বিভিন্ন অপ্টিমাইজেশন পর্যায় (দ্রুত পরিকল্পনার উপর লেনদেন প্রক্রিয়াজাতকরণ) ব্যবহার করে?

Question

এই সংযুক্ত আইটেমের উদাহরণ কোড

একটি বাগ প্রদর্শন করে যেখানে

SELECT COUNT(*)
FROM   dbo.my_splitter_1('2') L1
       INNER JOIN dbo.my_splitter_1('') L2
         ON L1.csv_item = L2.csv_item

সঠিক ফলাফল প্রদান করে। তবে নিম্নলিখিতগুলি ভুল ফলাফল (নতুন কার্ডিনালিটি অনুমান ব্যবহার করে 2014 এ) প্রদান করে

SELECT
    (SELECT COUNT(*)
    FROM dbo.my_splitter_1('2') L1
     INNER JOIN dbo.my_splitter_1('') L2
        ON L1.csv_item = L2.csv_item)

যেহেতু এটি ভুলভাবে L2 এর জন্য ফলাফলগুলি একটি সাধারণ সাব এক্সপ্রেশন স্পুলের মধ্যে লোড করে তারপরে এল 1 ফলাফলের ফলাফলটি পুনরায় প্রদর্শন করে।

আমি জানতে আগ্রহী ছিলাম কেন দুটি প্রশ্নের মধ্যে আচরণের মধ্যে পার্থক্য রয়েছে। ট্রেস পতাকা 8675 দেখায় যে কাজ করে search(0) - transaction processingসে প্রবেশ করে এবং ব্যর্থ হয় এমন একটি প্রবেশ করে search(1) - quick plan।

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

তবে কেন এই একই ধরণের প্রশ্নের দুটি পরিকল্পনা বিভিন্ন অপ্টিমাইজেশন পর্যায়ের মুখোমুখি হয়? আমি যা পড়েছি তার থেকে search (0)কমপক্ষে তিনটি টেবিল প্রয়োজন এবং সেই শর্তটি অবশ্যই প্রথম উদাহরণে মেটেনি।

Answer 1

প্রতিটি পর্যায়ে প্রবেশের শর্ত রয়েছে। "কমপক্ষে তিনটি টেবিলের রেফারেন্স থাকা" হ'ল সহজ উদাহরণ দেওয়ার ক্ষেত্রে আমরা প্রবেশের শর্তগুলির মধ্যে একটি, তবে এটি কেবলমাত্র এক নয়।

সাধারণত, 0 অনুসন্ধানে প্রবেশের জন্য কেবলমাত্র বেসিক যোগদান এবং ইউনিয়নগুলিকে অনুমতি দেওয়া হয়; স্কেলার সাবকিউরিজগুলি, অর্ধে যোগ দেয় ইত্যাদি অনুসন্ধানে প্রবেশের জন্য আটকে থাকে 0 এই পর্যায়েটি খুব সাধারণ ওলটিপি-টাইপ ক্যোয়ারী আকারগুলির জন্য। কম সাধারণ জিনিসগুলি অন্বেষণ করার জন্য প্রয়োজনীয় বিধিগুলি কেবল সক্ষম হয় না। আপনার উদাহরণ কোয়েরিতে একটি স্কেলার সাবকিউরি রয়েছে, সুতরাং এটি প্রবেশে ব্যর্থ।

এটি আপনি টেবিলের রেফারেন্সগুলি কীভাবে গণনা করেন তাও নির্ভর করে। আমি এর সাথে ফাংশনগুলির সাথে গভীরভাবে তাকাতে পারি নি, তবে সম্ভবত যুক্তিটি সারণি মূল্যবান ফাংশনগুলির পাশাপাশি তাদের উত্পাদিত সারণীর ভেরিয়েবলগুলি গণনা করছে। এমনকি এটি নিজেই ফাংশনের ভিতরে টেবিলের রেফারেন্স গণনা করতে পারে - আমি নিশ্চিত নই; যদিও আমি জানি যে ফাংশনগুলি কেবল চারপাশে কঠোর পরিশ্রম।

বাগটি GenGbApplySimpleকুরুচিপূর্ণ। এই পরিকল্পনার আকারটি সর্বদা একটি সম্ভাবনা ছিল, তবে 100-সারি ধরে নেওয়া টেবিলের পরিবর্তনশীল কার্ডিনালিটি পরিবর্তন না হওয়া পর্যন্ত ব্যয় কারণে প্রত্যাখ্যান করা হয়েছিল 2014 USE PLANউদাহরণস্বরূপ, ইঙ্গিত সহ 2014-পূর্বপূর্বে সমস্যাযুক্ত পরিকল্পনার আকারটি জোর করা সম্ভব ।

নতুন কানেক্ট আইটেমটি আগের হিসাবে একই সমস্যা হওয়ার বিষয়ে আপনি সঠিক ।

উদাহরণ দেওয়ার জন্য, নিম্নলিখিত কোয়েরি 0 টি অনুসন্ধানের জন্য যোগ্যতা অর্জন করে:

DECLARE @T AS table (c1 integer NULL);

SELECT U.c1, rn = ROW_NUMBER() OVER (ORDER BY U.c1) 
FROM 
(
    SELECT c1 FROM @T AS T
    UNION
    SELECT c1 FROM @T AS T
    UNION
    SELECT c1 FROM @T AS T
) AS U;

একটি স্কেলার সাবকিউরি অন্তর্ভুক্ত করতে একটি ছোট পরিবর্তন করা মানে এটি সরাসরি অনুসন্ধান 1 এ চলে যায়:

DECLARE @T AS table (c1 integer NULL);

SELECT U.c1, rn = ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) -- Changed!
FROM 
(
    SELECT c1 FROM @T AS T
    UNION
    SELECT c1 FROM @T AS T
    UNION
    SELECT c1 FROM @T AS T
) AS U;