@ পিয়ার 303 ইতিমধ্যে এটি বলেছে, তবে আমি এটি আবার বলব। আপনি কি কলামের সমন্বয় উপর ইনডেক্স ব্যবহার করুন। সংযুক্ত সূচকটি (a, b)কেবলমাত্র aসূচকের চেয়ে প্রশ্নের উপর কেবল সামান্য ধীর aএবং আপনার কোয়েরিটি উভয় কলামকে একত্রিত করে যদি ব্যাপকভাবে উন্নত হয়। কিছু ডাটাবেস টেবিলে আঘাত করার আগে aএবং এর bআগে সূচিতে যোগ দিতে পারে , তবে এটি সম্মিলিত সূচকের মতো প্রায় ভাল নয়। আপনি যখন একটি সম্মিলিত সূচক তৈরি করবেন তখন আপনার সম্মিলিত সূচীতে প্রথমে সর্বাধিক সন্ধান করা কলামটি দেওয়া উচিত।
যদি আপনার ডাটাবেস এটি সমর্থন করে তবে ডিও কলামগুলির চেয়ে ক্যোয়ারীতে প্রদর্শিত ফাংশনগুলিতে সূচি রাখুন। (আপনি যদি কোনও কলামে কোনও ফাংশন কল করে থাকেন তবে column কলামের সূচিগুলি অকেজো)
আপনি সত্য অস্থায়ী টেবিল সঙ্গে একটি ডাটাবেস ব্যবহার করে থাকেন যা আপনি তৈরি করতে পারেন এবং মাছি উপর ধ্বংস (যেমন পোস্টগ্রি মাইএসকিউএল, কিন্তু না ওরাকল), তারপর না অস্থায়ী টেবিলের উপর ইনডেক্স তৈরি করুন।
আপনি একটি ডাটাবেস এটি পারবেন (যেমন ওরাকল) ব্যবহার করেন, তাহলে আপনি কি ভাল ক্যোয়ারী পরিকল্পনায় লক। সময়ের সাথে সাথে ক্যোরি অপ্টিমাইজারগুলি কোয়েরি প্ল্যানগুলিকে পরিবর্তন করবে। তারা সাধারণত পরিকল্পনার উন্নতি করে। তবে কখনও কখনও তারা এটিকে নাটকীয়ভাবে আরও খারাপ করে তোলে। আপনি সাধারণত পরিকল্পনার উন্নতিগুলি লক্ষ্য করবেন না - ক্যোয়ারি কোনও বাধা ছিল না। তবে একটি একক খারাপ পরিকল্পনা ব্যস্ত সাইটটিকে নামিয়ে আনতে পারে।
না আপনার উপর অত্যধিক ডেটা লোড না করতে চলেছেন টেবিলের উপর ইনডেক্স আছে। সূচীগুলি ছেড়ে দেওয়া, ডেটা লোড করা, আপনি টেবিলটি লোড করার সাথে সাথে সূচীগুলি বজায় রাখার চেয়ে পুনর্নির্মাণ করা অনেক বেশি দ্রুত।
একটি বড় টেবিলের একটি ছোট ভগ্নাংশের চেয়ে বেশি অ্যাক্সেস করতে হবে এমন প্রশ্নের উপরে সূচকগুলি ব্যবহার করবেন না । (হার্ডওয়ারের উপরে কতটা ছোট নির্ভর করে 5 লিঙ্গ সূচীকরণে এটি কার্যকর হবে না যেহেতু আপনাকে এখনও 50% সারি অ্যাক্সেস করতে হবে। পরিবর্তে আপনি পুরো টেবিল স্ক্যানটি ব্যবহার করতে চান। কারণটি হ'ল সূচিগুলি এলোমেলোভাবে একটি বড় ফাইল অ্যাক্সেস করে, যার ফলে আপনার ডিস্ক সিকের প্রয়োজন হয়। ডিস্ক সিকস ধীর। পয়েন্ট হিসাবে একটি কেস হিসাবে আমি সম্প্রতি দেখেছি এমন এক ঘন্টা দীর্ঘ ক্যোয়ারীটি গতিতে পরিচালিত করেছি:
SELECT small_table.id, SUM(big_table.some_value)
FROM small_table
JOIN big_table
ON big_table.small_table_id = small_table.id
GROUP BY small_table.id
এটি নিম্নে পুনর্লিখন করে 3 মিনিটের নিচে যেতে:
SELECT small_table.id, big_table_summary.summed_value
FROM small_table
JOIN (
SELECT small_table_id, SUM(some_value) as summed_value
FROM big_table
GROUP BY small_table_id
) big_table_summary
ON big_table_summary.small_table_id = small_table.id
যা ডাটাবেসকে বুঝতে বাধ্য করেছিল যে এটি প্রলুব্ধকর সূচি ব্যবহার করার চেষ্টা করা উচিত নয় big_table.small_table_id। (ওরাকল এর মতো একটি ভাল ডাটাবেসটি নিজে থেকে এটি বের করা উচিত This এই কোয়েরিটি মাইএসকিউএল চলছিল))
আপডেট: এখানে আমি তৈরি করা ডিস্ক সন্ধানের পয়েন্টটির ব্যাখ্যা এখানে দেওয়া হয়েছে। একটি সূচী টেবিলে ডেটা কোথায় রয়েছে তা বলার জন্য একটি তাত্ক্ষণিক অনুসন্ধান দেয়। এটি সাধারণত একটি জয় যেহেতু আপনার কেবলমাত্র সেই ডেটাতে নজর দেওয়া দরকার যা আপনি দেখার প্রয়োজন। তবে সবসময় নয়, বিশেষত যদি আপনি অবশেষে প্রচুর ডেটা দেখেন। ডিস্কগুলি ডেটা স্ট্রিম ভাল করে, তবে লকআপগুলি ধীর করে দেয়। ডিস্কের ডেটাতে এলোমেলোভাবে সন্ধানের জন্য সেকেন্ডের 1/200 তম সময় লাগে। ক্যোয়ারির ধীর সংস্করণটি এর মধ্যে ,000০০,০০০ এর মতো কিছু করছে এবং এক ঘন্টার কাছাকাছি লেগেছে। (এটি এর চেয়ে আরও বেশি নজরদারি করেছে, তবে ক্যাশেগুলির মধ্যে কিছুটি ধরা পড়ে)) বিপরীতভাবে দ্রুত সংস্করণটি জানত যে এটি 70 এমবি / সেকেন্ডের মতো কিছুতে পড়তে হয়েছিল এবং ডেটা প্রবাহিত করে। এটি 3 মিনিটের নীচে 11 গিগাবাইট টেবিলের মাধ্যমে পেয়েছে।