কেন আমার পুরো ধারাটি "অন্তর্ভুক্ত" কলাম থেকে উপকৃত হবে?

Question

এই উত্তর অনুসারে , সীমাবদ্ধতার জন্য ব্যবহৃত কলামগুলির উপরে সূচি তৈরি না করা হলে ক্যোয়ারী কোনও সূচক থেকে উপকৃত হবে না।

আমার এই সংজ্ঞা আছে:

CREATE TABLE [dbo].[JobItems] (
    [ItemId]             UNIQUEIDENTIFIER NOT NULL,
    [ItemState]          INT              NOT NULL,
    [ItemPriority]       INT NOT NULL,
    [CreationTime]       DATETIME         NULL DEFAULT GETUTCDATE(),
    [LastAccessTime]     DATETIME         NULL DEFAULT GETUTCDATE(),
     -- other columns
 );

 CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex]
    ON [dbo].[JobItems]([ItemId] ASC);
 GO

CREATE INDEX [GetItemToProcessIndex]
    ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime])
    INCLUDE (LastAccessTime);
GO

এবং এই ক্যোয়ারী:

UPDATE TOP (150) JobItems 
SET ItemState = 17 
WHERE 
    ItemState IN (3, 9, 10)
    AND LastAccessTime < DATEADD (day, -2, GETUTCDATE()) 
    AND CreationTime < DATEADD (day, -2, GETUTCDATE());

আমি প্রকৃত পরিকল্পনাটি পর্যালোচনা করেছি, এবং প্রেডিকেটের সাথে ঠিক একই সূচকের সন্ধান পেয়েছি WHERE- LastAccessTimeসূচকটির অংশ না হয়ে সূচকটিতে কেবল "অন্তর্ভুক্ত" থাকা সত্ত্বেও পুনরুদ্ধার করার জন্য কোনও অতিরিক্ত "বুকমার্ক লুকআপস" নেই ।

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

আমি কি আচরণটি সঠিকভাবে পালন করি? WHEREঅন্তর্ভুক্ত কলাম থেকে আমার সুবিধাগুলি বা কলামটি সূচকের অংশ হওয়ার প্রয়োজন হলে আমি কীভাবে অগ্রিম জানতে পারি ?

Comments

এটি এখনও ItemStateমানের উপর ভিত্তি করে সন্ধান করতে পারে, তবে অনুসন্ধানটি ততটা দক্ষ হবে না যেমন আপনার সূচকটি নীচের মতো কাঠামোযুক্ত হয়েছিল(ItemState, CreationTime, LastAccessTime)

— মার্ক সিংকিনসন

@ মার্কসিংকনসন বা ঠিক(ItemState, CreationTime) INCLUDE (LastAccessTime)

— ypercubeᵀᴹ

@ শর্টপুথের আপনার লিঙ্কিত উত্তরটি এটি বলে না যে ("যদি না ক্যোমের সীমাবদ্ধ করতে ব্যবহৃত কলামগুলির উপরে একটি সূচক তৈরি না হয় তবে কোনও সূচক থেকে কোনও উপকার হবে না")। এটি বলে যে একটি সূচকের (a,b)সাথে ক্যোয়ারির জন্য সেরা নয় SELECT a FROM t WHERE b=5;এবং এটিতে একটি সূচক (b) INCLUDE (a)আরও ভাল।

— ypercubeᵀᴹ

Answer 1

আপনার ভবিষ্যদ্বাণীটি আপনার সিক প্রিডিকেট থেকে আলাদা।

সিক প্রিডিকেট ইনডেক্সে অর্ডার করা ডেটা অনুসন্ধান করতে ব্যবহৃত হয়। এই ক্ষেত্রে এটি তিনটি সন্ধান করবে, আপনার আগ্রহী প্রতিটি আইটেমস্টেটের জন্য একটি করে। এর বাইরেও ডেটা আইটেমপ্রাইরিটি অর্ডারে রয়েছে, সুতরাং আর কোনও "সিক" অপারেশন করা যাবে না।

তবে ডেটা ফেরত দেওয়ার আগে, এটি প্রতিদ্বন্দ্বী ব্যবহার করে প্রতিটি সারি পরীক্ষা করে যা আমি রেসিডুয়াল প্রিডিকেট হিসাবে উল্লেখ করি। এটি অনুসন্ধানের পূর্বাভাসের ফলাফলগুলিতে সম্পন্ন হয়েছে।

যে কোনও অন্তর্ভুক্ত কলামটি অর্ডার করা তথ্যের অংশ নয়, তবে অতিরিক্ত লুকআপ না করেই অবশিষ্ট পূর্বাভাসকে সন্তুষ্ট করতে ব্যবহার করা যেতে পারে।

सार्গ্যাবিলিটির চারপাশে আমি এই লিখিত উপাদানটি দেখতে পাচ্ছি। বিশেষত এসকিউএলবিটস-এ http://bit.ly/Sargability এ একটি সেশনের জন্য পরীক্ষা করুন

সম্পাদনা করুন: রেসিডুয়ালের প্রভাব আরও ভালভাবে দেখানোর জন্য, অনির্ধারিত ব্যবহার করে ক্যোয়ারী চালান OPTION (QUERYTRACEON 9130), যা রেসিডিয়ালকে আলাদা ফিল্টার অপারেটরে আলাদা করে দেবে (যা বাস্তবে সিক অপারেটরে স্থানান্তরিত হওয়ার আগে পরিকল্পনার পূর্ববর্তী সংস্করণ)। এটি ফিল্টার থেকে বামে সারি সংখ্যা নির্ধারণ করে, একটি অকার্যকর সিকের প্রভাব স্পষ্টভাবে দেখায়।

এটিও লক্ষণীয় যে আইটেমস্টেটের আইএন দফার কারণে, ডেটা বামে করা তথ্যটি আসলে আইটেমস্টেট ক্রমে থাকে, আইটেমপ্রাইরিটির ক্রমে নয়। আইটেম স্টেটে একটি যৌগিক সূচক যার পরে তারিখগুলির মধ্যে একটি (যেমন (আইটেমস্টেট, লাস্টঅ্যাকসেসটাইম)) ব্যবহার করা যেতে পারে তিনটি সিক (সিক প্রিডিকেট এক সিক অপারেটরের মধ্যে তিনটি সিক দেখায়), প্রতিটি দুটি স্তরের বিপরীতে, তথ্য তৈরি করে যা এখনও আইটেমস্টেট ক্রমে (উদাঃ আইটেমস্টেট = 3 এবং লাস্টএ্যাকসেসটাইম কোনও কিছুর চেয়ে কম, তারপরে আইটেমস্টেট = 9 এবং লাস্টএ্যাকসেসটাইম কোনও কিছুর চেয়ে কম এবং তারপরে আইটেমস্টেট = 10 এবং লাস্টএ্যাকসেসটাইম কোনও কিছুর চেয়ে কম)।

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

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

রেসিডুয়াল প্রিডিকেট শব্দটি অনুসারে - একজন সন্ধানীর এই সম্পত্তিটির জন্য এটি আমার নিজস্ব শব্দ। মার্জ জয়েন স্পষ্টতই একে এর সমপরিমাণ একটি রেসিডুয়াল প্রিডিকেট বলে এবং হ্যাশ ম্যাচ একে একে প্রোব রেসিডুয়াল (যা আপনি হ্যাশের সাথে ম্যাচ করলে টিএসএ থেকে পেতে পারে) বলে। তবে সিকের মধ্যে তারা একে একে প্রিডিকেট বলে যার ফলে এটি এর চেয়ে কম খারাপ মনে হয়।

Answer 2

গেটআইটিটোপ্রসেস ইন্ডেক্স সম্পূর্ণরূপে অনুসন্ধানযোগ্য নয় কারণ আপনার যেখানে ক্লজ চালু রয়েছে ItemState + LastAccessTime + CreationTime। সূচকযুক্ত কলাম এবং যেখানে ধারাটি একটি নিখুঁত মিল নয়।

আপনি যদি ItemState + LastAccessTime + CreationTimegetItemToProcessIndex থেকে প্রাপ্ত প্রতিটি ম্যাচের জন্য একটি প্রচ্ছদ সূচক তৈরি করেন তবে আপনি আপনার প্রাথমিক কী (আইটেমআইডি) এর মানও পাবেন। এটি কেবলমাত্র নিশ্চিত করতে হবে যে ২ য় তারিখটি একটি ম্যাচ।

তারপরে তার পৃষ্ঠার সারিটির অবস্থানে ঝাঁপিয়ে পড়ে এটি আপডেট করার জন্য আপনাকে কেবল এটি প্রয়োজন।

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