টেবিলটি খুচরা বিক্রেতা_ সম্পর্কিতগুলি নিম্নলিখিত সম্মিলিত পিকে সূচক এবং প্রস্তাবিত সূচক-
অনুপস্থিত সূচীগুলি সহায়ক হতে পারে এবং অবশ্যই কাজ করতে পারে, আমি অনুপস্থিত সূচকগুলিতে খুব বেশি সময় ব্যয় করব না, এই ইঙ্গিতগুলি প্রকৃত বাস্তবায়ন পরিকল্পনার পরিবর্তে নয়, আনুমানিক বাস্তবায়ন পরিকল্পনায় তৈরি করা হয়েছে।
আরও স্পষ্টভাবে, এই সূচীকরণের ইঙ্গিতগুলি পরিকল্পনায় অপারেটরদের দ্বারা ব্যবহৃত কোয়েরি ব্যয়ের ব্যয় হ্রাস করার ভিত্তিতে রয়েছে। অপ্টিমাইজারটি আনুমানিক ব্যয়ের গণনা করে এবং সেই অনুসারে অনুপস্থিত সূচক ইঙ্গিতগুলি যোগ করে।
ফলস্বরূপ তারা খুব ভুল হতে পারে। আপনি যদি অনিশ্চিত হন যে এটি যদি সহায়তা করে চলেছে, তবে সবচেয়ে ভাল কাজটি হ'ল আগে এবং পরে পরিস্থিতি পরীক্ষা করা। আপনি SET STATISTICS IO, TIME ON;কোয়েরি চালানোর আগে বিবৃতি যোগ করে এটি করতে পারেন
।
এছাড়াও, আপনি এই পরিসংখ্যানগুলি পড়তে আরও সহজ করার জন্য স্ট্যাটিস্টিক পার্সার ব্যবহার করতে পারেন ।
এটি কি সূচকের কলামগুলির ক্রমের কারণে হতে পারে?
এটি সঠিক, অনুপস্থিত সূচী তৈরি করা প্রশ্নগুলিতে নির্বাচনগুলি উন্নত করতে পারে, উদাহরণস্বরূপ যদি আপনার ক্যোয়ারীটি এমন দেখাচ্ছে:
SELECT RelatedRetailerID
FROM Retailer_Relations
WHERE
RetailerID = 5 AND
RelationType = 20;
বা এই মত:
SELECT RelatedRetailerID
FROM Retailer_Relations
ORDER BY
RetailerID,
RelationType;
এর পিছনে যুক্তিটি হ'ল উভয় সূচীই খুচরা বিক্রেতা আইডিতে সন্ধান করতে পারে, সেই অংশটি পরিবর্তন হতে পারে না। তবে রিলেশনটাইপ-এ অতিরিক্ত ফিল্টার / অর্ডারিং প্রয়োগ করা হলে কী হবে? এটি ক্লাস্টারড ইনডেক্সের পুরো জায়গা জুড়ে থাকবে, ফলস্বরূপ এটি তৃতীয় কী মান হবে, দ্বিতীয় কী মান নয়। এবং যেমনটি আমরা জানি, এটি এনসিআইয়ের দ্বিতীয় কী মান।
ঠিক আছে, তবে কখন বা কীভাবে অবিবাহিত সূচি কোয়েরিটি উন্নত করবে?
কয়েকটি মামলা হতে পারে:
- যদি রিলেশনটাইপ অনেকগুলি মান ফিল্টার করে, অবশিষ্ট I / O উচ্চতর হতে পারে, ফলে অবিবাহিত সূচকের সম্ভাব্য প্রয়োজন হয় (ক্যোয়ারী # 1)
- দুটি কলামে অর্ডারিং ঘটে (এক উপায়), এবং ফলাফলটি বড় (ক্যোয়ারী # 2)।
- যেমন @ অ্যারোনবার্ট্র্যান্ড উল্লেখ করেছে: এনসিআইয়ের তুলনায় সিআই আকারের পার্থক্য যদি যথেষ্ট পরিমাণে হয় তবে এনসিআই যুক্ত করলে তাতে উপকৃত প্রশ্নের দ্বারা পড়া পৃষ্ঠাগুলি হ্রাস পাবে।
এনসিআই সাইড নোট
পার্শ্ব নোট হিসাবে, আপনার এনসিআইতে অন্তর্ভুক্ত তালিকায় কী কলামগুলি যুক্ত করা ঠিক তেমন প্রয়োজন হয় না, যেহেতু সিআই কী কলামগুলি স্বয়ংক্রিয়ভাবে সমস্ত নন ক্লাস্টারযুক্ত সূচকে অন্তর্ভুক্ত থাকে।
যদি আপনি নিশ্চিত না হন যে ক্লাস্টারড সূচকটি একই থাকবে এবং আপনি কলামটি সর্বদা অন্তর্ভুক্ত থাকতে চান তবে আপনি এটি করতে বেছে নিতে পারেন।
নিজেই ক্যোয়ারির বিষয়ে, আপনি যদি পেস্টেপ্লোনের মাধ্যমে কার্যকরকরণ পরিকল্পনাটি যুক্ত করেন তবে আমরা কোয়েরিটিকে সূচীকরণ / উন্নত করার বিষয়ে আরও কিছু তথ্য দিতে পারি।
পরীক্ষামূলক
টেবিল তৈরি করুন এবং কয়েকটি সারি যুক্ত করুন
CREATE TABLE Retailer_Relations (
RetailerID int ,
RelatedRetailerID int ,
RelationType smallint,
CreatedOn datetime,
CONSTRAINT PK_Retailer_Relations
PRIMARY KEY CLUSTERED (
RetailerID ASC,
RelatedRetailerID ASC,
RelationType ASC
) ON [PRIMARY])
DECLARE @I Int = 1
WHILE @I < 1000
BEGIN
INSERT INTO Retailer_Relations(RetailerID,RelatedRetailerID,RelationType,CreatedOn)
VALUES(@I,@I,@I,GETDATE()
)
set @I += 1
END
প্রশ্ন # 1
SELECT RelatedRetailerID
FROM Retailer_Relations
WHERE
RetailerID = 5 AND
RelationType = 20;
সূচী ছাড়াই পরিকল্পনা করুন এখানে
এটি যখন সন্ধান করছে তখন এটি খুচরা বিক্রেতা আইডিতে একটি অনুসন্ধান করছে। এরপরে এটি রিলেশনটাইপ-এ একটি অবশিষ্ট অবশিষ্ট আই / ও প্রিকিকেট জারি করা হচ্ছে
সূচি যোগ করুন
CREATE NONCLUSTERED INDEX IX_TEST
ON Retailer_Relations (
RetailerID,
RelationType
)
INCLUDE (
RelatedRetailerID
)
উভয় কলামে অবশেষের প্রাকটিকালটি চলে গেছে, একটি অনুসন্ধানের শিকারে সবকিছু ঘটে যায়।
হত্যা পরিকল্পনা
দ্বিতীয় ক্যোয়ারির সাথে, যুক্ত সূচক সাহায্যকারীতা আরও স্পষ্ট হয়ে ওঠে:
SELECT RelatedRetailerID
FROM Retailer_Relations
ORDER BY
RetailerID,
RelationType;
বাছাই করা অপারেটরের সাথে সূচক ছাড়াই পরিকল্পনা করুন:
সূচকের সাথে পরিকল্পনা করুন, সূচীটি ব্যবহার করে বাছাই করা অপারেটরটি সরানো হবে
