ক্লাস্টারড ইনডেক্স স্ক্যান কার্যকর করার সংখ্যা এত বেশি কেন?

Question

আমার দুটি অনুরূপ ক্যোয়ারী রয়েছে যা একই ক্যোয়ারী প্ল্যান উত্পন্ন করে, একটি ক্যোয়ারী প্ল্যান 1316 বার একটি ক্লাস্টারড ইনডেক্স স্ক্যান সম্পাদন করে, অন্যটি এটি 1 বার কার্যকর করে।

দুটি প্রশ্নের মধ্যে একমাত্র পার্থক্য হ'ল ভিন্ন তারিখের মানদণ্ড। দীর্ঘ চলমান ক্যোয়ারী আসলে সংক্ষিপ্ত তারিখের মানদণ্ড এবং কম ডেটা টেনে নিয়ে যায়।

আমি এমন কিছু সূচিগুলি সনাক্ত করেছি যা উভয় প্রশ্নের সাথে সহায়তা করবে, তবে আমি কেবল বুঝতে চাই যে ক্লাস্টারড ইনডেক্স স্ক্যান অপারেটর কেন এমন প্রশ্নের উপর 1316 বার চালাচ্ছে যা কার্যত যেখানে এটি 1 বার কার্যকর হয় তার সমান।

আমি যে পিকে স্ক্যান করা হচ্ছে তার পরিসংখ্যানগুলি পরীক্ষা করেছিলাম এবং সেগুলি অপেক্ষাকৃত আধুনিক।

মূল ক্যোয়ারী:

select distinct FIR_Incident.IncidentID
from FIR_Incident
left join (
    select incident_id as exported_incident_id
    from postnfirssummary
) exported_incidents on exported_incidents.exported_incident_id = fir_incident.incidentid
where FI_IncidentDate between '2011-06-01 00:00:00.000' and '2011-07-01 00:00:00.000'
    and exported_incidents.exported_incident_id is not null

এই পরিকল্পনাটি তৈরি করে:

তারিখের পরিসীমা মানদণ্ড সঙ্কুচিত করার পরে:

select distinct FIR_Incident.IncidentID
from FIR_Incident
left join (
    select incident_id as exported_incident_id
    from postnfirssummary
) exported_incidents on exported_incidents.exported_incident_id = fir_incident.incidentid
where FI_IncidentDate between '2011-07-01 00:00:00.000' and '2011-07-02 00:00:00.000'
    and exported_incidents.exported_incident_id is not null

এই পরিকল্পনাটি তৈরি করে:

Comments

আপনি কি ইমেজ ফাইলগুলির পরিবর্তে কোনও কোড ব্লকে আপনার প্রশ্নগুলি অনুলিপি / পেস্ট করতে পারবেন?

— এরিক হামফ্রে - লটশেল্প

অবশ্যই - আমি প্রতিটি পরিকল্পনা তৈরি করে এমন প্রশ্নের যোগ করেছি।

— সেয়েবর

ক্লাস্টারড ইনডেক্স স্ক্যানটি কোন টেবিলে ঘটছে?

— এরিক হামফ্রে - লটশেল্প

ক্লাস্টারড ইনডেক্স স্ক্যানটি বাম জোয়ারের সাবকিউরিতে রয়েছে (পোস্টএনএফআইআরআইএসআইএসএসম্যারি)

— সেবার

সম্ভবত সর্বশেষে পরিসংখ্যান আপডেট করা হয়েছিল সেখানে শূন্য বা এক সারি FI_IncidentDate between '2011-07-01 00:00:00.000' and '2011-07-02 00:00:00.000'মাপদণ্ড পূরণ করে এবং তখন থেকেই সেই ব্যাপ্তিতে অসম্পূর্ণ সংখ্যার সন্নিবেশ ঘটেছে। এটি অনুমান করে যে সেই তারিখের জন্য কেবলমাত্র 1.07 মৃত্যুদণ্ডের প্রয়োজন হবে। বাস্তবে আসন্ন 1,316 নয়।

— মার্টিন স্মিথ

Answer 1

স্ক্যানের পরে যোগদানকারী একটি ক্লু দেয়: সর্বশেষ যোগদানের একদিকে কম সারি সহ (অবশ্যই ডান থেকে বামে পড়া) অপটিমাইজার একটি "নেস্ট লুপ" বেছে নেয় না "হ্যাশ জয়েন"।

যাইহোক, এটি দেখার আগে আমি কী লুকআপ এবং DISTINCT বাদ দেওয়ার লক্ষ্য রাখি।

• মূল অনুসন্ধান: আপনার সূচকটি FIR_Incident- তে অবশ্যই (FI_IncidentDate, incidentid)বা অন্য কোনও উপায়ে beেকে রাখা উচিত । অথবা উভয়ই আছে এবং দেখুন যা বেশি বেশি ব্যবহৃত হয় (তারা উভয়ই হতে পারে)

• এর DISTINCTপরিণতি LEFT JOIN ... IS NOT NULL। আশাবাদী ইতিমধ্যে এটি মুছে ফেলেছে (পরিকল্পনাগুলি "চূড়ান্ত যোগদানের সাথে" অর্ধ যোগদান করবে ") তবে আমি স্পষ্টতার জন্য বিদ্যমান ব্যবহার করব

কিছুটা এইরকম:

select 
    F.IncidentID
from 
    FIR_Incident F
where 
    exists (SELECT * FROM postnfirssummary P
           WHERE P.incident_id = F.incidentid)
    AND
    F.FI_IncidentDate between '2011-07-01 00:00:00.000' and '2011-07-02 00:00:00.000'

আপনি এসকিউএল সার্ভারকে একটি হ্যাশ যোগ দিতে ব্যবহারের জন্য পরিকল্পনার গাইড এবং যোগ ইঙ্গিতগুলিও ব্যবহার করতে পারেন, তবে প্রথমে এটিকে স্বাভাবিকভাবে কাজ করার চেষ্টা করুন: কোনও গাইড বা একটি ইঙ্গিত সম্ভবত সময়ের পরীক্ষায় দাঁড়াবে না কারণ এগুলি কেবল ডেটা জন্য কার্যকর এবং আপনি এখন চালানো ক্যোয়ারী, ভবিষ্যতে নয়