অপশন (রিকম্পাইল) না করে সূচী SEEK ব্যবহার করা হবে না?


11

(এসও থেকে প্রশ্ন সরানো হয়েছে)

ক্লাস্টারড ইনডেক্স সহ আমার একটি টেবিল (ডামি ডেটা) রয়েছে 2 টি কলাম রয়েছে:

এখানে চিত্র বর্ণনা লিখুন

এখন আমি এই দুটি প্রশ্ন চালাচ্ছি:

declare 
@productid int =1 , 
@priceid  int = 1




SELECT productid,
       t.priceID
FROM   Transactions AS t
WHERE  (productID = @productid OR @productid IS NULL)
       AND (priceid = @priceid OR @priceid IS NULL)  


SELECT productid,
       t.priceID
FROM   Transactions AS t
WHERE  (productID = @productid)
       AND (priceid = @priceid)

উভয় প্রশ্নের জন্য প্রকৃত বাস্তবায়ন পরিকল্পনাটি হ'ল:

এখানে চিত্র বর্ণনা লিখুন

আপনি দেখতে পাচ্ছেন, প্রথমটি স্ক্যান ব্যবহার করছে যখন দ্বিতীয়টি সেক ব্যবহার করছে।

যাইহোক - OPTION (RECOMPILE)প্রথম ক্যোয়ারীতে যুক্ত করে এসইকে ব্যবহারের জন্য এক্সিকিউশন প্ল্যানও তৈরি করেছে:

এখানে চিত্র বর্ণনা লিখুন

ডিবিএ আড্ডায় বন্ধুরা আমাকে বলেছিল:

আপনার ক্যোয়ারিতে, @ producttid = 1, যার অর্থ (productID = @ productID বা @ productID NULL) (productID = @ productID) এ সরলীকৃত করা যেতে পারে। প্রাক্তনটির @ প্রোডাক্টআইডিএডের কোনও মান নিয়ে কাজ করার জন্য একটি স্ক্যান প্রয়োজন, পরে কোনও সন্ধান করতে পারে। সুতরাং, যখন আপনি RECOMPILE ব্যবহার করবেন, এসকিউএল সার্ভার আপনার কাছে @ প্রোডাক্টআইডিএডে আসলে কতটা মূল্য আছে তা দেখবে এবং এর জন্য সেরা পরিকল্পনা করবে। @ উত্পাদকআইডি-এ একটি নন-নাল মান সহ, একটি সন্ধানটি সেরা is যদি @ প্রোডাক্টআইডিটির মান অজানা থাকে তবে পরিকল্পনাকে @ প্রোডাক্টআইডিআইডি-তে কোনও সম্ভাব্য মানের সাথে মানিয়ে নিতে হবে, যার জন্য একটি স্ক্যান দরকার। সতর্কতা অবলম্বন করুন: অপশন (রিকম্পাইল) আপনি যখনই এটি চালাবেন ততবার পরিকল্পনার পুনরায় সংকলন করতে বাধ্য করবে, যা প্রতিটি সম্পাদনে কয়েক মিলিসেকেন্ড যুক্ত করবে। যদিও কোয়েরিটি খুব ঘন ঘন চলতে পারে তবে এটি কেবল একটি সমস্যা।

এছাড়াও:

@ প্রোডাক্টআইডিডিটি যদি নাল হয় তবে আপনি কোন মানটির সন্ধান করবেন? উত্তর: খোঁজ করার মতো কিছুই নেই। সমস্ত মান যোগ্যতা অর্জন করে।

আমি বুঝতে পারি যে OPTION (RECOMPILE)এসকিউএল সার্ভারকে প্যারামিটারগুলির প্রকৃত মূল্যবোধগুলি দেখতে বাধ্য করে এবং এটি এটি অনুসন্ধান করতে পারে কিনা তা দেখুন।

তবে এখন আমি সামনের-সংকলনের সুবিধাটি হারাচ্ছি।

প্রশ্ন

আইএমএইচও - স্ক্যান কেবল তখনই ঘটে যখন কোনও প্যারাম শূন্য থাকে।
এটি ঠিক আছে - এসকিউএল সার্ভারকে স্ক্যানের জন্য একটি কার্যকরকরণ পরিকল্পনা তৈরি করতে দিন।
কিন্তু যদি এসকিউএল সার্ভার দেখতে পায় যে আমি এই কোয়েরিটি বহুবার মান সহ চালাচ্ছি: 1,1তবে কেন এটি অন্য কোনও কার্যনির্বাহী পরিকল্পনা তৈরি করে এবং এর জন্য অনুসন্ধান ব্যবহার করে না?

আফাইক - এসকিউএল সর্বাধিক হিট প্রশ্নের জন্য কার্যকরকরণ পরিকল্পনা তৈরি করে ।

  • এসকিউএল সার্ভার কেন একটি সম্পাদন পরিকল্পনা সংরক্ষণ করে না:

    @productid int =1 , @priceid int = 1

(আমি এই মানগুলি দিয়ে বহুবার চালাই)

  • ভবিষ্যতের অনুরোধের জন্য - এসকিউএলকে সেই কার্যকরকরণ পরিকল্পনা (যা সেক ব্যবহার করে) রাখার জন্য বাধ্য করা সম্ভব?

সম্পূর্ণ তৈরি টেবিল স্ক্রিপ্ট + ডেটা


উত্তর:


10

আমাদের চ্যাট রুম আলোচনার মূল পয়েন্টগুলির সংক্ষিপ্তসার :


সাধারণভাবে বলতে গেলে, SQL সার্ভার একটি ক্যাশে প্রতিটি বিবৃতি জন্য একক পরিকল্পনাভবিষ্যতের সমস্ত সম্ভাব্য প্যারামিটার মানগুলির জন্য সেই পরিকল্পনাটি অবশ্যই বৈধ হতে হবে

এটা একটা ক্যাশে করা সম্ভব নয় চাইতে , আপনার প্রশ্নের জন্য পরিকল্পনা কারণ যে পরিকল্পনা বৈধ হবে না যদি, উদাহরণস্বরূপ, @productid নাল হয়।

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

সাধারণ সমস্যা শ্রেণি

আপনার ক্যোয়ারী এমন একটি প্যাটার্নের উদাহরণ যা বিভিন্নভাবে "সমস্ত ক্যাচ করুন" বা "গতিশীল অনুসন্ধান" ক্যোয়ারী হিসাবে উল্লেখ করা হয়। বিভিন্ন নিজস্ব সমাধান এবং অসুবিধাগুলি সহ বিভিন্ন সমাধান রয়েছে। এসকিউএল সার্ভারের আধুনিক সংস্করণগুলিতে (২০০৮+) প্রধান বিকল্পগুলি হ'ল:

  • IF ব্লক
  • OPTION (RECOMPILE)
  • গতিশীল এসকিউএল ব্যবহার করে sp_executesql

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

IF ব্লক

IFপ্রশ্নের নির্দিষ্ট ক্ষেত্রে একটি ব্লক সমাধান চিত্রিত করতে :

IF @productid IS NOT NULL AND @priceid IS NOT NULL
BEGIN
    SELECT 
        T.productID,
        T.priceID
    FROM dbo.Transactions AS T
    WHERE
        T.productID = @productid
        AND T.priceID = @priceid;
END;
ELSE IF @productid IS NOT NULL
BEGIN
    SELECT 
        T.productID,
        T.priceID
    FROM dbo.Transactions AS T
    WHERE
        T.productID = @productid;
END;
ELSE IF @priceid IS NOT NULL
BEGIN
    SELECT 
        T.productID,
        T.priceID
    FROM dbo.Transactions AS T
    WHERE
        T.priceID = @priceid;
END;
ELSE
BEGIN
    SELECT 
        T.productID,
        T.priceID
    FROM dbo.Transactions AS T;
END;

এতে দুটি প্যারামিটারের প্রতিটি (বা স্থানীয় ভেরিয়েবল) এর জন্য সম্ভাব্য চারটি নাল-বা-নল মামলার পৃথক বিবৃতি রয়েছে, সুতরাং চারটি পরিকল্পনা রয়েছে।

প্যারামিটার স্নিফিংয়ের সাথে সেখানে একটি সম্ভাব্য সমস্যা রয়েছে যার OPTIMIZE FORজন্য প্রতিটি প্রশ্নের জন্য কোনও ইঙ্গিতের প্রয়োজন হতে পারে । এই ধরণের সূক্ষ্মতাগুলি আবিষ্কার করতে রেফারেন্স বিভাগটি দেখুন।

কম্পাইল

প্রশ্নের একটি উপরে উল্লিখিত হিসাবে, আপনি OPTION (RECOMPILE)প্রতিটি অনুরোধে একটি নতুন পরিকল্পনা (সন্ধান বা স্ক্যান) পেতে একটি ইঙ্গিতও যুক্ত করতে পারেন। আপনার ক্ষেত্রে কলগুলির তুলনামূলকভাবে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে কম দেওয়া (একবারে প্রতি দশ সেকেন্ডে একবারে সাব-মিলিসেকেন্ড সংকলনের সময় দিয়ে) সম্ভবত মনে হয় এই বিকল্পটি আপনার পক্ষে উপযুক্ত হবে:

SELECT
    T.productID,
    T.priceID
FROM dbo.Transactions AS T
WHERE
    (T.productID = @productid OR @productid IS NULL)
    AND (T.priceID = @priceid OR @priceid IS NULL)
OPTION (RECOMPILE);

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

আরও পড়া

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.