এক্সিকিউশন প্ল্যান INDEX ব্যবহার করছে না, এটি টেবিল স্ক্যান ব্যবহার করে

9

আমি জানি যখন সূচক বা টেবিল স্ক্যান ব্যবহার করার কথা আসে তখন এসকিউএল সার্ভার পরিসংখ্যান ব্যবহার করে কোনটি আরও ভাল তা দেখার জন্য।

আমার কাছে 20 মিলিয়ন সারি সহ একটি টেবিল রয়েছে। (স্ন্যাপশটকি, পরিমাপ) এবং এই কোয়েরিতে আমার একটি সূচক রয়েছে:

select Measure, SnapshotKey, MeasureBand
from t1
where Measure = 'FinanceFICOScore'
group by Measure, SnapshotKey, MeasureBand

ক্যোয়ারী 500k সারি দেয়। সুতরাং কোয়েরিটি টেবিলের সারিগুলির মাত্র 2.5% নির্বাচন করে।

প্রশ্নটি হ'ল এসকিউএল সার্ভার আমার থাকা ননক্লাস্টারড সূচকটি কেন ব্যবহার করে না এবং পরিবর্তে একটি টেবিল স্ক্যান ব্যবহার করে?

পরিসংখ্যান আপডেট করা হয়।

ক্যোরির পারফরম্যান্স যদিও ভাল তা উল্লেখ করা ভাল।

টেবিল স্ক্যান

জোরপূর্বক সূচক

সারণী / সূচক কাঠামো

CREATE TABLE [t1](
    [SnapshotKey] [int] NOT NULL,
    [SnapshotDt] [date] NOT NULL,
    [Measure] [nvarchar](30) NOT NULL,
    [MeasureBand] [nvarchar](30) NOT NULL,
    -- and many more fields
) ON [PRIMARY]

টেবিলে কোনও পিকে নেই, কারণ এটি ডেটা গুদাম।

CREATE NONCLUSTERED INDEX [nci_SnapshotKeyMeasure] ON [t1]
(
    [SnapshotKey] ASC,
    [Measure] ASC
)

16

আপনি যদি অনেকগুলি সারি এবং / অথবা সারিগুলি খুব প্রশস্ত করে থাকেন তবে সূচক সন্ধানটি সেরা পছন্দ নাও হতে পারে। আপনার সূচকটি coveringেকে না রাখলে চেহারাগুলি ব্যয়বহুল হতে পারে। এখানে # 2 দেখুন ।

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

অপ্টিমাইজার সর্বদা সর্বনিম্ন ব্যয় বিকল্পটিকে বিবেচনা করে। দুটি কার্যকরকরণ পরিকল্পনার মূল নোডের আনুমানিক সাবট্রি কস্ট সম্পত্তিটি যদি আপনি দেখেন তবে আপনি দেখতে পাবেন যে স্ক্যান পরিকল্পনার সিক পরিকল্পনার চেয়ে কম আনুমানিক ব্যয় রয়েছে। ফলস্বরূপ, অপটিমাইজার স্ক্যানটি বেছে নিয়েছিল। এটিই আপনার প্রশ্নের উত্তর।

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

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

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

— হারুন বার্ট্র্যান্ড
সূত্র

9

আপনার কাছে আসলে 595,947 টি সারি সারি রয়েছে যা আপনার ডেটার প্রায় 3%। সুতরাং দেখার ব্যয়টি দ্রুত যুক্ত হয়। ধরুন আপনার টেবিলটিতে প্রতি পৃষ্ঠায় 100 টি সারি রয়েছে, এটি টেবিল স্ক্যানে পড়ার জন্য 200,000 পৃষ্ঠা pages এটি 595,947 লুকআপ করার চেয়ে অনেক সস্তা।

সঙ্গে GROUP BYপ্রশ্নে দফা, আমি মনে করি আপনি (মেজার, SnapshotKey, MeasureBand) এ একটি যৌগিক কী দিয়ে ভাল বন্ধ হবেন।

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

উদাহরণস্বরূপ, ক্যোয়ারির জন্য:

select Measure, SnapshotKey, MeasureBand, SUM(NumLoans), SUM(PrinBal)
from t1
where Measure = 'FinanceFICOScore'
group by Measure, SnapshotKey, MeasureBand

... আপনার প্রয়োজন হবে:

CREATE INDEX ixWhatever 
ON t1 (Measure, SnapshotKey, MeasureBand) 
INCLUDE (NumLoans,PrinBal);

— রব ফারলে
সূত্র

6

আপনার WHERE অবস্থার ক্ষেত্রটি সূচকের শীর্ষস্থানীয় ক্ষেত্র নয়।
আপনি measureএনভিআচআরএআর হিসাবে সংজ্ঞায়িত করেছেন তাই আক্ষরিক সাথে একটি N: সহ উপস্থাপন করুন where Measure = N'FinanceFICOScore'।

একটি ক্লাস্টার ইনডেক্স চালু করার বিষয়ে বিবেচনা করুন SnapshotKey। যদি এটি অনন্য হয় তবে এটি পিকে (এবং ক্লাস্টারড) হতে পারে। যদি অনন্য না হয় তবে এটি পিকে হতে পারে না, তবে এটি একটি অনন্য-অনন্য ক্লাস্টারড সূচক হতে পারে। তারপরে আপনার অ ক্লাস্টারযুক্ত সূচকটি কেবল measureকলামে থাকবে।

এবং, বিবেচনা করা যে প্রথম ক্ষেত্র GROUP BYহয় measure, এছাড়াও থাকার থেকে উপকৃত হবে measureনেতৃস্থানীয় ক্ষেত্র হবে।

প্রকৃতপক্ষে, এই অপারেশনের জন্য, আপনাকে ক্লাসটির সাথে মিলে যায় এমন পরিবর্তে আপনাকে ননক্র্লাস্টারড ইনডেক্সের পরিবর্তে সংজ্ঞা দিতে Measure, SnapshotKey, MeasureBandহবে GROUP BY। আকার-অনুসারে যা কেবলমাত্র যোগ করা হচ্ছে MeasureBandযেহেতু নন-ক্লাস্টারড সূচকটি ইতিমধ্যে ভিত্তিক রয়েছে Measure, এবং MeasureKeyএটি ইতিমধ্যে ক্লাস্টারড ইনডেক্স কী হিসাবে রয়েছে (ইতিমধ্যে, নন-ক্লাস্টারড সূচীতে Measureনকল হবে না) সূচীতে অন্তর্ভুক্ত রয়েছে।

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

— সলোমন রুটজকি
সূত্র

এই উত্তরের আলোচনাটি চ্যাটে সরানো হয়েছে ।

— পল হোয়াইট 9