আরও দক্ষ কী, যেখানে মিলিয়ন প্লাস সারি টেবিলগুলির সাথে ক্লজ বা একটি যোগদান?

Question

আমরা একটি ওয়েবসাইট চালিত করি যার একটি টেবিলে 250 মিমি সারি রয়েছে এবং অন্য সারণীতে আমরা এটিতে যোগ দিয়েছি বেশিরভাগ প্রশ্নের জন্য কেবল 15 এমএম সারি রয়েছে।

নমুনা কাঠামো:

MasterTable (Id, UserId, Created, Updated...) -- 15MM Rows
DetailsTable (Id, MasterId, SomeColumn...) -- 250MM Rows
UserTable (Id, Role, Created, UserName...) -- 12K Rows

এই সমস্ত টেবিলের বিরুদ্ধে আমাদের নিয়মিত কয়েকটি প্রশ্ন করতে হবে। একটি হ'ল নিখরচায় ব্যবহারকারীদের জন্য পরিসংখ্যান দখল করা (free 10 কে ফ্রি ব্যবহারকারী)।

Select Count(1) from DetailsTable dt 
join MasterTable mt on mt.Id = dt.MasterId 
join UserTable ut on ut.Id = mt.UserId 
where ut.Role is null and mt.created between @date1 and @date2

সমস্যা হ'ল সমস্যাটি হ'ল এই কোয়েরিটি কোথাও কোথাও অনেক আগে দীর্ঘ মিলন ঘটায় এই ঘটনার সাথে মিলিত হওয়ার কারণে।

এক্ষেত্রে যোগদানের পরিবর্তে বা সম্ভবত ব্যবহারের পরে চাকাগুলি ব্যবহার করা কি বুদ্ধিমানের কাজ হবে where column in(...)?

Comments

কি ডাটাবেস এবং সংস্করণ?

— লেফ রিফেল

আপনি উভয় উপায়ে চেষ্টা করেছেন?

— gbn

যদি এটি ওরাকল হয় তবে আমি এনভিএল 2 (রোল, এনএলএল, আইডি) এর ইউজারবেলটির জন্য একটি ফাংশন ভিত্তিক সূচক তৈরি করব, তবে এটি অন্য ডিবির মতো দেখাচ্ছে।

— লেফ রিফেল

Answer 1

আধুনিক আরডিবিএমএসের জন্য "সুস্পষ্ট জোইন" এবং "জোইন-ইন-দ্য WHERE" (যদি সমস্ত জয়েন্টস ইনর থাকে) পারফরম্যান্স এবং ক্যোয়ারী পরিকল্পনার ক্ষেত্রে কোনও পার্থক্য নেই।

সুস্পষ্ট জোইন সিনট্যাক্সটি পরিষ্কার এবং কম अस्पष्ट (নীচের লিঙ্কগুলি দেখুন)

এখন, যোগ-এর আগে-কোথায় লজিক্যাল প্রসেসিং প্রকৃত প্রসেসিং নয় এবং আধুনিক আশাবাদীরা এটি উপলব্ধি করার পক্ষে যথেষ্ট চালাক।

আপনার সমস্যাটি সম্ভবত সূচকগুলি।

দয়া করে আমাদের এই টেবিলের সমস্ত সূচি এবং কীগুলি দেখান। এবং কোয়েরি পরিকল্পনা

দ্রষ্টব্য: এই প্রশ্নটি এখনই ডুপ্লিকেট হওয়ার কারণে স্ট্যাক ওভারফ্লোতে খুব কাছাকাছি থাকত ... COUNT (1) বনাম COUNT (*) এটিও একটি অন্যরকম মিথ্যা কল্পকাহিনী।

• /programming/5654278/sql-join-is-there-a-difference-between-using-on-or-where/5654338#5654338
• /programming/3003457/count-vs-countcolumn-name-which-is-more-correct/3003533#3003533
• /programming/1221559/count-vs-count1/1221649#1221649

Comments

এটি সবসময় সত্য নয় যে joinএবং whereদফাটির মধ্যে কোনও পার্থক্য নেই । আমি দীর্ঘ সময় ধরে চলমান জিজ্ঞাসাগুলি সর্বদা অপ্টিমাইজ করি এবং কখনও কখনও whereক্লজ ব্যবহার joinকরা প্রশ্নগুলি 70x পর্যন্ত ফ্যাক্টর দ্বারা ব্যবহারকারীর চেয়ে ভাল সম্পাদন করে । এটি যদি এত সরল এবং সোজা ছিল, জীবন সমস্ত বৃষ্টি এবং এককৃর্ণ ছিল। আর এই কিছু প্রাচীন অস্পষ্ট ইঞ্জিন সম্পর্কে নয় - ডান এখন আমি 70x সুবিধা দিকে তাকিয়ে রইলাম whereএসকিউএল 2012 সালে দফা

— ajeh

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

— আজ

@ আজেহ: আমি আপনাকে পরামর্শ দিচ্ছি যে আপনার অভিজ্ঞতাটি অত্যন্ত টিপিকাল। যদি আপনি x70 পার্থক্য রয়েছে আপনি প্রশ্নের সঙ্গে বড় বিষয় আছে: এটা যে সহজ

— gbn

Answer 2

আপনাকে কোয়েরিটি পুরোপুরি রিফ্যাক্টর করতে হবে

পূর্বে WHERE ক্লজগুলি এবং JOIN গুলি পরে সম্পাদনের চেষ্টা করুন

Select Count(1) from DetailsTable dt
join (Select UserId,Id FROM MasterTable where
created between @date1 and @date2) mt on mt.Id = dt.MasterId 
join (Select Id FROM UserTable WHERE Role is NULL) ut
on ut.Id = mt.UserId;

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

আমি এই ইউটিউব ভিডিও থেকে এই ধারণা পেয়েছি ।

আমি স্ট্যাকওভারফ্লোতে একটি জটিল প্রশ্নে ভিডিও থেকে নীতিগুলি চেষ্টা করেছিলাম এবং 200 পয়েন্টের অনুদান পেয়েছি।

@gbn আপনার জায়গায় সঠিক সূচক রয়েছে তা নিশ্চিত করার কথা উল্লেখ করেছে। এই ক্ষেত্রে, দয়া করে মাস্টার টেবেলে তৈরি কলামটি সূচী করুন।

একবার চেষ্টা করে দেখো !!!

আপডেট ২০১১-০6-২২ 22:31 ইডিটি

আপনার এই প্রশ্নগুলি চালানো উচিত:

SELECT COUNT(1) AllRoles FROM UserTable;
SELECT COUNT(1) NullRoles FROM UserTable WHERE Role is NULL;

যদি নলরোলস এক্স 20 <অলরোলস (অন্য কথায়, যদি নালরোলস কম হয় তবে টেবিলের সারিগুলির 5%), আপনার ইউজারবেলটিতে একটি অনন্য-অনন্য সূচক তৈরি করা উচিত। অন্যথায়, ইউজার টেবিলের একটি সম্পূর্ণ সারণি যথেষ্ট হবে কারণ ক্যোরি অপ্টিমাইজারটি সম্ভবত কোনও সূচক ব্যবহার করে প্রত্যাখ্যান করতে পারে।

আপডেট করুন 2011-06-25 12:40 ইডিটি

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

Answer 3

আমাদের প্রায় 75M সারিগুলির একটি [বিশদ] টেবিল ছিল; একটি [মাস্টার] প্রায় 400K সারি এবং একটি সম্পর্কিত [আইটেম] টেবিল যা সর্বদা এবং চিরকাল 7 টি সারি ছিল। এটি "আইটেম নম্বর" (1-7) এর ছোট সেটটি সংরক্ষণ করে এবং একটি কাগজ ফর্ম মডেলিং করছিল, যার লক্ষ লক্ষ প্রতি মাসে মুদ্রিত এবং বিতরণ করা হত distributed কার্টেসিয়ান যোগদানের ব্যবহারের সাথে জড়িত থাকার বিষয়ে আপনি সবচেয়ে আগে সম্ভবত সবচেয়ে আগে জিজ্ঞাসা করেছিলেন query আইআইআরসি, এটি এমন কিছু ছিল:

SELECT m.order_id, i.line_nr, d.Item_amt
FROM Master m, Item i 
INNER JOIN Detail d ON m.order_id = d.order_id

[আইটেম] এবং [বিস্তারিত] এর মধ্যে লজিক্যাল "আইডি" লিঙ্ক থাকা সত্ত্বেও আন্তঃজৌিনের চেয়ে ক্রস জয়েন্ট আরও ভাল কাজ করেছে।

আরডিবিএমএস ছিল এমপিপি প্রযুক্তি সহ টেরাদাতা, এবং ইনডেক্সিং স্কিমটি আইডিআর। টেবল স্ক্যান সর্বদা সেরা সঞ্চালিত হওয়ায় 7 সারি সারণির কোনও সূচি ছিল না।