ইনডেক্স তৈরি করার সময় কেন অন্তর্ভুক্ত ক্লজটি ব্যবহার করবেন?

Question

70-433 পরীক্ষার জন্য অধ্যয়ন করার সময় আমি লক্ষ্য করেছি যে আপনি নিম্নলিখিত দুটি উপায়ে যেকোন একটিতে একটি কভারিং সূচক তৈরি করতে পারেন।

CREATE INDEX idx1 ON MyTable (Col1, Col2, Col3)

- বা -

CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)

ইনক্লুড ক্লজটি আমার কাছে নতুন। আপনি কেন এটি ব্যবহার করবেন এবং ইনক্লুড ক্লজটি সহ বা ছাড়াই কোনও প্রচ্ছদ সূচক তৈরি করবেন কিনা তা নির্ধারণে আপনি কী নির্দেশিকা নির্দেশ করবেন?

Answer 1

কলামটি যদি না থাকে WHERE/JOIN/GROUP BY/ORDER BYতবে কেবল SELECTঅনুচ্ছেদে কলামের তালিকায় রয়েছে ।

INCLUDEদফা বরং সূচক গাছ তুলনায় সর্বনিম্ন / পাত পর্যায়ে তথ্য যোগ করা হয়েছে। এটি সূচকে ছোট করে কারণ এটি গাছের অংশ নয়

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

একটি কাজের উদাহরণ সহ আরও একটি এমএসডিএন নিবন্ধ

Comments

তাহলে, এটি কোনও কভারড ইনডেক্সের কম ব্যয়বহুল সংস্করণ তৈরি করার কৌশল হবে?

— জেমার্চ

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

— টোলা ওদেজয়ী

@ জেমার্চ: দেরিতে জবাবের জন্য দুঃখিত, তবে হ্যাঁ, এটি ঠিক তাই।

— gbn

@ তোলা ওদেজয়ী: ইনক্লুড কলামগুলি সূচকে কী কলাম নয় তাই সেগুলি অর্ডার করা হয়নি। এটি এগুলিকে জিন বা বাছাই করার জন্য সাধারণত দরকারী না করে তোলে । এবং এগুলি কী কলাম নয়, তাই তারা কী কলামগুলির মতো পুরো বি-ট্রি কাঠামোয় বসে না

— gbn

যদিও এটি সর্বাধিক গৃহীত উত্তর, আমি মনে করি আরও ব্যাখ্যা করা দরকার, যদি কিছু প্রশ্নের জন্য কলামটি অংশটির অংশ হয় SELECTএবং কিছু না হয়? \

— চিস্কো

Answer 2

আপনি ক্লাস্টারবিহীন সূচকের পাতার স্তরে এক বা একাধিক কলাম যুক্ত করতে অন্তর্ভুক্ত ব্যবহার করবেন, যদি এটি করে আপনি আপনার প্রশ্নগুলি "কভার" করতে পারেন।

ভাবুন আপনার কোনও কর্মীর আইডি, বিভাগের আইডি এবং পদবি ব্যবহারের প্রয়োজন আছে query

SELECT EmployeeID, DepartmentID, LastName
FROM Employee
WHERE DepartmentID = 5

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

আপনি যদি নিজের সূচকে সেই শেষ নামটি অন্তর্ভুক্ত করে থাকেন:

CREATE NONCLUSTERED INDEX NC_EmpDep 
  ON Employee(EmployeeID, DepartmentID)
  INCLUDE (Lastname)

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

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

Comments

আপনি কি নিশ্চিত যে আপনি এই সূচকটি ব্যবহার করবেন? কর্মচারী কেন? আপনার কেবল কী কলামগুলিতে বিভাগীয় আইডি দরকার? আপনি এখানে যেমন authoratitive উদ্ধৃত করা হয়েছে: stackoverflow.com/q/6187904/27535

— gbn

আপনার ব্যাখ্যা ভাল তবে আসলে আপনি যে রূপরেখাটি উল্লেখ করেছেন সেটির সাথে মিল নেই line মূল কলাম (গুলি) ফিল্টার বা JOINক্যোয়ারীর কীগুলিতে থাকা উচিত এবং আপনার INCLUDEযে তথ্য পুনরুদ্ধার করছেন তা বাছাই করা নয় এমন হওয়া দরকার।

— জেএনকে

সমস্ত সূচকের প্রথমত কর্মচারী (কর্মচারী,

— ডিভিশনআইডি) বিভাগের আইডিএফ

Answer 3

এই আলোচনা গুরুত্বপূর্ণ পয়েন্ট হাতছাড়া হয়: প্রশ্ন না হয় যদি "অ-কি-কলাম" আরও ভাল হয় যেমন অন্তর্ভুক্ত করা সূচক -columns বা অন্তর্ভুক্ত -columns।

প্রশ্নটি হল যে সূচকগুলিতে সত্যই প্রয়োজন হয় না এমন কলামগুলি অন্তর্ভুক্ত করার জন্য অন্তর্ভুক্ত-প্রক্রিয়াটি ব্যবহার করা কত ব্যয়বহুল ? (সাধারণত যেখানে-ক্লজগুলির অংশ নয়, তবে প্রায়শই নির্বাচনগুলির অন্তর্ভুক্ত থাকে)। সুতরাং আপনার দ্বিধা সর্বদা:

1. আইডি 1, আইডি 2 ... আইডিএন একা বা
2. উপর id1, id2 ... আইডিএন সূচক ব্যবহার প্লাস অন্তর্ভুক্ত col1, col2 ... colN

যেখানে: আইডি 1, আইডি 2 ... আইডিএন হ'ল কলামগুলি প্রায়শই বিধিনিষেধে ব্যবহৃত হয় এবং কল 1, কল 2 ... কলএন প্রায়শই কলামগুলি নির্বাচিত হয়, তবে সাধারণত বিধিনিষেধে ব্যবহৃত হয় না

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

তাহলে বিকল্প 1 বা 2 ব্যবহার করবেন?

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

আপনি যে কলামগুলি অন্তর্ভুক্ত-কলামগুলি হিসাবে যুক্ত মনে করেন তা যদি প্রায়শই আপডেট হয় (সূচি ছাড়াই- কী -কলামগুলি আপডেট হচ্ছে না) - বা - যদি এটি এত বেশি হয় যে সূচকটি আপনার টেবিলের অনুলিপিটির নিকটবর্তী হয় - বিকল্প 1 ব্যবহার করুন আমি পরামর্শ দিই! এছাড়াও যদি কিছু অন্তর্ভুক্ত কলাম (গুলি) যুক্ত করা হয় তবে কোনও পারফরম্যান্স-পার্থক্য না ঘটে - আপনি সেগুলি যুক্ত করার ধারণাটি এড়িয়ে যেতে পারেন :) সেগুলি কার্যকর কিনা তা যাচাই করুন!

কীগুলিতে একই মান প্রতি সারির গড় সংখ্যা (আইডি 1, আইডি 2 ... আইডিএন) পাশাপাশি কিছুটা গুরুত্বপূর্ণ হতে পারে।

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

Answer 4

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

Answer 5

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

Comments

এটি প্রমাণ করার কোনও উপায় আছে যে এটি আসলে কম স্মৃতি ব্যবহার করছে? এটিই আমি প্রত্যাশা করছিলাম তবে আমি কাজের বিষয়ে এই বিষয়ে কিছু স্থির করছি

— আস্কেন

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

— mrdenny

Answer 6

একটি অতিরিক্ত বিবেচনা যা আমি ইতিমধ্যে প্রদত্ত জবাবগুলিতে দেখিনি, এটি হ'ল অন্তর্ভুক্ত কলামগুলি এমন ডেটা জাতীয় ধরণের হতে পারে যা সূচক কী কলাম যেমন ভেরচার (সর্বোচ্চ) হিসাবে অনুমোদিত নয়।

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

Answer 7

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

আপনার উদাহরণ বিবেচনা:

CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)

আপনার ক্যোয়ারীটি এমন দেখাচ্ছে যদি সেই সূচকটি সেরা:

SELECT col2, col3
  FROM MyTable
 WHERE col1 = ...

আপনি INCLUDEকী অংশে অতিরিক্ত সুবিধা পেতে পারেন তা অবশ্যই আপনার কলামগুলি লাগানো উচিত নয় । নিম্নলিখিত উভয় প্রশ্নেরই col2সূচকের কীতে কলামটি আসলে পছন্দ করবে ।

SELECT col2, col3
  FROM MyTable
 WHERE col1 = ...
   AND col2 = ...

SELECT TOP 1 col2, col3
  FROM MyTable
 WHERE col1 = ...
 ORDER BY col2

এর অনুমান করা এই হল যাক না কেস এবং আমরা আছে col2যে INCLUDEধারা না থাকায় শুধু সূচক বৃক্ষ অংশে এটা থাকার কোন লাভ।

দ্রুত কয়েক বছর এগিয়ে।

আপনার এই ক্যোয়ারির টিউন করা দরকার:

SELECT TOP 1 col2
  FROM MyTable
 WHERE col1 = ...
 ORDER BY another_col

এই ক্যোয়ারীটি অনুকূল করতে, নিম্নলিখিত সূচকটি দুর্দান্ত হবে:

CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2)

যদি আপনি এই টেবিলটিতে ইতিমধ্যে আপনার সূচকগুলি পরীক্ষা করে থাকেন তবে আপনার পূর্ববর্তী সূচকটি এখনও সেখানে থাকতে পারে:

CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)

এখন আপনি তা জানেন Col2এবং Col3সূচক গাছের অংশ নন এবং এটি পঠন সূচির পরিসর সংকীর্ণ করতে বা সারিগুলি অর্ডার করার জন্য ব্যবহৃত হয় না। another_columnইন্ডেক্সের মূল অংশটির শেষে (পরে col1) যুক্ত করা বরং নিরাপদ । কিছু ভাঙার ঝুঁকি কম:

DROP INDEX idx1 ON MyTable;
CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2, Col3);

সেই সূচকটি আরও বড় হয়ে উঠবে, যার এখনও কিছু ঝুঁকি রয়েছে, তবে নতুন সূচনার তুলনায় বিদ্যমান সূচীগুলি বাড়ানো সাধারণত ভাল।

আপনার যদি একটি সূচক ছাড়া থাকে INCLUDE, আপনি another_colঠিক কী পরে যুক্ত করে কোন প্রশ্নগুলি ভাঙবেন তা আপনি জানতে পারবেন না Col1।

CREATE INDEX idx1 ON MyTable (Col1, Col2, Col3)

যদি আপনি এবং এর another_colমধ্যে যোগ করেন তবে কী হবে ? অন্যান্য প্রশ্নের ক্ষতি হবে?Col1Col2

INCLUDEবনাম কী কলামগুলির অন্যান্য "সুবিধা" রয়েছে যদি আপনি এই কলামগুলি কেবল টেবিল থেকে আনতে না চান তবে তা যুক্ত করুন । যাইহোক, আমি ডকুমেন্টেশন দিকটিকে সবচেয়ে গুরুত্বপূর্ণ হিসাবে বিবেচনা করি।

আপনার প্রশ্নের উত্তর দিতে:

ইনক্লুড ক্লজটি সহ বা ছাড়াই কোনও প্রচ্ছদ সূচক তৈরি করতে হবে তা নির্ধারণে আপনি কোন গাইডলাইনসের পরামর্শ দিবেন?

আপনি যদি টেবিলটি না দেখে সূচকে এই কলামটি উপলভ্য করার একমাত্র উদ্দেশ্যে সূচকে একটি কলাম যুক্ত করেন তবে এটিকে INCLUDEধারাটিতে রেখে দিন।

যদি সূচী কীতে কলামটি যুক্ত করা হয় তবে অতিরিক্ত সুবিধা (যেমন এর জন্য order byবা এটি পড়ার সূচির পরিসরকে সংকুচিত করতে পারে) এটিকে কীটিতে যুক্ত করুন।

আপনি এই সম্পর্কে একটি দীর্ঘ আলোচনা পড়তে পারেন:

https://use-the-index-luke.com/blog/2019-04/include-columns-in-btree-indexes

Answer 8

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

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