কেন এই কোয়েরিটি আমার অবিচ্ছিন্ন সূচকটি ব্যবহার করছে না এবং আমি কীভাবে এটি তৈরি করতে পারি?


12

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

এই ক্যোয়ারী প্রায় 2.5 সেকেন্ডে চলে:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31';

এটি প্রায় 33 এমএসে চলে:

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

[আইডি] ক্ষেত্রে (পিকে) একটি ক্লাস্টার্ড সূচক রয়েছে এবং [ডেটইন্টারড], [ডিভাইসআইডি] -এ একটি ক্লাস্টারযুক্ত সূচক রয়েছে। প্রথম ক্যোয়ারি ক্লাস্টারড ইনডেক্স ব্যবহার করে, দ্বিতীয় ক্যোয়ারীটি আমার নন-ক্লাস্টার্ড ইনডেক্স ব্যবহার করে। আমার প্রশ্ন দুটি অংশ:

  • কেন, যেহেতু উভয় প্রশ্নের জিজ্ঞাসার [ডেটইন্টারড] ক্ষেত্রটিতে একটি বিধি রয়েছে, তাই সার্ভারটি কি প্রথমে ক্লাস্টার ইনডেক্স ব্যবহার করে তবে দ্বিতীয়টি নয়?
  • অর্ডারবাই ছাড়াই কীভাবে আমি এই প্রশ্নটিতে নন ক্লাস্টারযুক্ত সূচকটি ডিফল্টরূপে ব্যবহার করতে পারি? (বা আমি কেন এমন আচরণ চাইব না?)

ডেটএন্টার্ড একটি ডেটটাইম, এক্ষেত্রে আমি তারিখের অংশটি ব্যবহার করি তবে আমি মাঝে মাঝে তারিখ এবং সময় উভয়ের বিপরীতে জিজ্ঞাসা করি।
নট

উত্তর:


9

প্রথম ক্যোয়ারীটি আমি যে থ্রোসোল্ডের উপরে ভিত্তি করে আগে ব্যাখ্যা করেছি একটি টেবিল স্ক্যান করে: লক্ষ লক্ষ সারি দিয়ে একটি সংকীর্ণ টেবিলের উপর কোয়েরি কার্যকারিতা বাড়ানো কি সম্ভব?

(সম্ভবত TOP 1000ক্লজ ছাড়াই আপনার ক্যোয়ারী 46k সারি আরও বেশি ফিরে আসবে some বা এমন কিছু যেখানে 35k এবং 46k এর মধ্যে রয়েছে (ধূসর অঞ্চল ;-))

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

ধারাটিতে কলামগুলির ক্রমটি বিপরীত করুন ORDER BYএবং এনসি আইএনডেক্স অকেজো হয়ে যাওয়ার পরে আপনি একটি ক্লাস্টারড ইনডেক্স স্ক্যানে ফিরে এসেছেন।

সম্পাদনা আপনার দ্বিতীয় প্রশ্নের উত্তর ভুলে গেছে, কেন আপনি এটি চান না

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

এখানে কীটি র‌্যান্ডম। এনসি সূচীতে পাওয়া প্রতিটি সারির জন্য, অ্যাক্সেসের পদ্ধতিগুলি ক্লাস্টারড ইনডেক্সে একটি নতুন পৃষ্ঠা সন্ধান করতে হবে। এটি এলোমেলো এবং তাই খুব ব্যয়বহুল।

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

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

এখন, ORDER BYপুরো ক্লাস্টারড ইনডেক্সটি স্ক্যান করা এবং তারপরে ফলাফলগুলি অর্ডার করা আরও ব্যয়বহুল করে তোলে। পরিবর্তে, অপ্টিমাইজারটি ধরে নিয়েছে যে অলড্রি অর্ডার করা এনসি ইনডেক্সটি ব্যবহার করা সস্তা এবং তারপরে বুকমার্কের অনুসন্ধানগুলির জন্য এলোমেলো আইও জরিমানা দিতে হবে।

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

আপনার ক্ষেত্রে, যতক্ষণ আপনার সন্নিবেশগুলি প্রবেশের তারিখ দ্বারা অর্ডার করা হয়, যতক্ষণ আড্ডায় এবং পূর্ববর্তী প্রশ্নে আলোচনা করা হয়েছে (লিঙ্কটি দেখুন) আপনি প্রবেশের তারিখ কলামে ক্লাস্টারড সূচক তৈরি করার চেয়ে ভাল।


20

বিভিন্ন সিনট্যাক্স ব্যবহার করে ক্যোয়ারী প্রকাশ করা কখনও কখনও অপ্টিমাইজারের কাছে একটি ক্লাস্টারবিহীন সূচক ব্যবহার করার আপনার ইচ্ছাটি যোগাযোগ করতে সহায়তা করে। আপনার নীচের ফর্মটি সন্ধান করা উচিত যা আপনার পছন্দসই পরিকল্পনাটি দেয়:

SELECT
    [ID],
    [DeviceID],
    [IsPUp],
    [IsWebUp],
    [IsPingUp],
    [DateEntered]
FROM [dbo].[Heartbeats]
WHERE
    [ID] IN
(
    -- Keys
    SELECT TOP (1000)
        [ID]
    FROM [dbo].[Heartbeats]
    WHERE 
        [DateEntered] >= CONVERT(datetime, '2011-08-30', 121)
        AND [DateEntered]  < CONVERT(datetime, '2011-08-31', 121)
);

অনুসন্ধান পরিকল্পনা

নন-ক্লাস্টারড সূচককে ইঙ্গিত সহ বাধ্য করা হলে উত্পাদিত পরিকল্পনার সাথে সেই পরিকল্পনার তুলনা করুন:

SELECT TOP (1000) 
    * 
FROM [dbo].[Heartbeats] WITH (INDEX(CommonQueryIndex))
WHERE 
    [DateEntered] BETWEEN '2011-08-30' and '2011-08-31';

জোর করে সূচক ইঙ্গিত পরিকল্পনা

পরিকল্পনাগুলি মূলত একই রকম (কী লুকআপ ক্লাস্টারড ইনডেক্সে সন্ধান ছাড়া আর কিছুই নয়)। উভয় পরিকল্পনার ফর্মগুলি কেবল ক্লাস্টারযুক্ত সূচকের জন্য একবার অনুসন্ধান এবং ক্লাস্টারড ইনডেক্সে সর্বাধিক 1000 লুকআপের কাজ সম্পাদন করবে।

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

স্ক্যান এবং সিক্সের ব্যয়

খুব উচ্চ স্তরে, স্ক্যানগুলি এবং সিক্সের জন্য অপ্টিমাইজারের ব্যয় মডেলটি বেশ সহজ: এটি অনুমান করে যে 320 এলোমেলো সিক্সের স্ক্যানের 1350 পৃষ্ঠা পড়ার মতোই ব্যয় হয় । এটি সম্ভবত কোনও নির্দিষ্ট আধুনিক আই / ও সিস্টেমের হার্ডওয়্যার ক্ষমতার সাথে সামান্য সাদৃশ্য রাখে তবে এটি একটি ব্যবহারিক মডেলের পাশাপাশি যুক্তিসঙ্গতভাবে কাজ করে।

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

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

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

সারি লক্ষ্য

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

এই উত্তরের চিত্রগুলি এসকিউএল সেন্ট্রি প্ল্যান এক্সপ্লোরার ব্যবহার করে তৈরি করা হয়েছিল ।

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