উচ্চ নির্বাচন এবং নিম্ন নির্বাচনী ক্ষেত্রগুলির সাথে সম্মিলিত সূচক ক্রমের ক্ষেত্র ক্রম

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

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[এনরোল_ডেট] হ'ল 50 টিরও কম মান সহ একটি নিম্ন নির্বাচনী কলাম, অন্যদিকে ইউজারআইডি কলামটি 200 মিলিয়নেরও বেশি স্বতন্ত্র মানের সহ একটি উচ্চ নির্বাচিতকরণ কলাম। আমার গবেষণার ভিত্তিতে আমি বিশ্বাস করি যে এই দুটি কলামে আমার একটি ক্লাস্টারবিহীন যৌগিক সূচক তৈরি করা উচিত এবং তাত্ত্বিকভাবে উচ্চতর নির্বাচনী কলামটি প্রথম কলাম হওয়া উচিত। তবে আমি আমার ক্ষেত্রে নিশ্চিত নই, তা কি কাজ করবে কারণ আমি দলে দলে গ্রুপে নিম্ন নির্বাচনী কলামটি ব্যবহার করছি।

এই টেবিলটির কোনও ক্লাস্টার ইনডেক্স নেই।

sql-server index nonclustered-index

— Thinkinger
সূত্র

আপনি কি বাস্তব এক্সিকিউশন প্ল্যান এক্সএমএল পোস্ট করতে পারেন (পেস্টবিন ব্যবহার করুন এবং এটি এখানে লিঙ্ক করুন)? আপনি স্কেল সার্ভারের কোন সংস্করণ ব্যবহার করছেন?

— কিন শাহ

প্রথমে অত্যন্ত নির্বাচিত কলামের সূচক নির্দিষ্ট প্রশ্নের জন্য অকেজো হবে।

— ypercubeᵀᴹ

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

— পলবার্বিন

উত্তর:

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

আমি সাধারনত "সেরা অনুশীলন" হিসাবে উচ্চ-নির্বাচনের সূচকগুলিকে সুপারিশ করব না, বরং সূচকটি আপনার ক্যোয়ারিকে সেরা পারফরম্যান্স দেবে তা দেখুন look

এর উপর একটি সূচক (Enroll_Date, UserID)আপনার ক্যোয়ারিকে স্ট্রিম সমষ্টিগুলির সাথে একটি উচ্চতর অনুকূলিত, নন-ব্লকিং ক্যোয়ারী পরিকল্পনা দেবে।

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

— ড্যানিয়েল হুটমাচার
সূত্র

মজার, 4 সেকেন্ডের ব্যবধানে এবং একই উত্তর।

— usr ডিরেক্টরির

অ্যারনস উত্তর একটি দুর্দান্ত সমাধান। আপনি এই পদ্ধতিটি গ্রহণ করতে চান না এই ধারণা করে আমি প্রশ্নের উত্তর দেব।

আপনি যে ক্যোয়ারী পোস্ট করেছেন তা সাধারণত প্রথম গ্রুপিং দ্বারা চালিত হবে (Enroll_Date, UserID), তারপরে আবারও (Enroll_Date)। এই অপটিমাইজেশনটি এসকিউএল সার্ভার ২০১২-তে নতুন। এটি একক ক্ষেত্রে কার্যকর হয় COUNT DISTINCT।

নির্দিষ্ট ক্রমে এই দুটি কলামের একটি সূচক (Enroll_Date, UserID)একটি কার্যকর পরিকল্পনা পাওয়ার জন্য পর্যাপ্ত হবে যা ধারাবাহিকভাবে দুটি স্ট্রিম সমষ্টিগুলিতে একটি সূচক স্ক্যান তৈরি করে। বিপরীত অর্ডার সেই পরিকল্পনা সক্ষম করবে না।

সুতরাং, আদেশ ব্যবহার করুন (Enroll_Date, UserID)। এখানে আপনার কোন পছন্দ নেই।

— usr ডিরেক্টরির
সূত্র

5 সেকেন্ডের ব্যবধানে এবং একই সমাধান। ভাল খেলেছে স্যার। :)

— ড্যানিয়েল হাটমাচার

@ ড্যানিয়েল হাটমাচার ওএমজি, আমরা কি তৃতীয়বারের মতো আমাদের পোস্টগুলির সাথে প্রায় মিল করতে পারি ?! আপনাকে +1! আমি কীভাবে একটি অভিন্ন উত্তর উপস্থাপন করতে পারি না ?

— usr ডিরেক্টরির

ম্যাট্রিক্সে ভুল। :)

— ড্যানিয়েল হাটমাচার

আপনাকে অনেক ধন্যবাদ. আমি সূচকটি তৈরি করছি এবং এটি সম্পন্ন হওয়ার পরে উন্নতি পোস্ট করব। সার্ভার সংস্করণটি এডাব্লুএসে মাইক্রোসফ্ট এসকিউএল সার্ভার ২০০৮ আর 2, তবে আমি অনুমান করি যে এটি নির্বিশেষে এখনও একমাত্র উপস্থাপক।

— Thinkinger

ক্ষেত্রে @Thinkinger আপনি গ্রহণ করছেন না আরনস কাছে আপনি একটি কঠিন পছন্দ :) পেয়েছেন

— usr ডিরেক্টরির

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

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

এটি তৈরি করতে কিছুটা সময় লাগবে এবং অবশ্যই বেস টেবিলের সূচির মতো সমস্ত ডিএমএল ক্রিয়াকলাপের রক্ষণাবেক্ষণের প্রয়োজন হবে।

এখন এই দৃশ্যের বিপরীতে কোয়েরিটি একই রকম হবে - ভিউয়ের প্রতিটি সারি এখন একটি পৃথক ব্যবহারকারী / তারিখের কম্বো উপস্থাপন করে, যাতে সেই চিত্রটি একটি একক COUNT (*) দ্বারা গণনা করা যায়, যখন বেস টেবিলের সারিগুলির মোট সংখ্যা is ইতিমধ্যে আপনার জন্য আংশিকভাবে একত্রিত হয়েছে, এখন কেবল আপনাকে প্রতি তারিখের জন্য এসএমএম ব্যবহার করে এগুলি যুক্ত করতে হবে:

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date;

NOEXPAND ইঙ্গিতটি দিনের কথা মনে পরে যোগ করা এই এবং এই ।

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

এবং যদি আপনি নির্দিষ্ট, সুনির্দিষ্ট-সংজ্ঞায়িত রেঞ্জগুলির জন্য এনরোল_ডেটের বিপরীতে একই সাধারণ WHERE ধারাগুলি ব্যবহার করেন (বলুন, বর্তমান ত্রৈমাসিক বা তারিখের বছর) তবে আপনি মিলে যাওয়া ফিল্টার সূচকগুলি যোগ করতে পারেন যা I / O আরও কমিয়ে দেয় (তবে সর্বদা একটি আছে ভারসাম্য).

আপনি বেস টেবিলের উপর একটি ক্লাস্টার্ড সূচক স্থাপন বিবেচনা করতে পারেন। এটি খুব বিরল ব্যবহারের কেসগুলির মধ্যে একটি বলে মনে হয় না যে গাদা থেকে উপকারী।

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

আমি কেবল আমাদের আইটি দিয়ে নিশ্চিত করেছি এবং মনে হচ্ছে আমি এই ধরণের দৃশ্য তৈরি করতে পারি না। তবে এখনও আপনার পরামর্শকে প্রশংসা করুন এবং এটি অন্যকে যারা এটি ব্যবহার করতে পারে তাদের সহায়তা করবে।

— Thinkinger

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

— অ্যারন বার্ট্র্যান্ড

@ টিঙ্কিংগার এছাড়াও, সূচিবদ্ধ দর্শনগুলি কেবল ইই নয়। সূচক দর্শন মেলানো কেবল EE-। আপনি তাদেরকে NOEXPAND ব্যবহার করে সরাসরি টার্গেট করতে পারেন।

— usr ডিরেক্টরির