আপনাকে অবশ্যই প্রথম বিষয়টি জানতে হবে যে সূচিগুলি হ'ল আপনি যে ফলাফলটি সন্ধান করছেন তা পাওয়ার জন্য পুরো টেবিলটি স্ক্যান করা এড়ানো।
বিভিন্ন ধরণের সূচক রয়েছে এবং সেগুলি স্টোরেজ স্তরটিতে প্রয়োগ করা হয়, সুতরাং তাদের মধ্যে কোনও মান নেই এবং তারা যে স্টোরেজ ইঞ্জিনটি ব্যবহার করছেন তার উপরও নির্ভর করে।
ইনোডিবি এবং বি + ট্রি সূচক
InnoDB- র জন্য, সর্বাধিক সাধারণ সূচক প্রকারটি হ'ল বি + ট্রি ভিত্তিক সূচক, যা উপাদানগুলি সাজানো ক্রমে সংরক্ষণ করে। এছাড়াও, আপনাকে সূচিযুক্ত মানগুলি পেতে সত্যিকারের টেবিলটি অ্যাক্সেস করতে হবে না, যা আপনার ক্যোয়ারীটিকে দ্রুত ফেরানোর পথে দ্রুততর করে তোলে।
এই সূচক প্রকারের "সমস্যা" হ'ল আপনাকে সূচকটি ব্যবহার করতে বামতম মানের জন্য জিজ্ঞাসা করতে হবে। সুতরাং, যদি আপনার সূচকের দুটি কলাম থাকে, শেষ_নাম এবং প্রথম নামটি বলুন, আপনি এই ক্ষেত্রগুলিকে জিজ্ঞাসা করার ক্রমটি অনেক গুরুত্বপূর্ণ ।
সুতরাং, নিম্নলিখিত টেবিল দেওয়া:
CREATE TABLE person (
last_name VARCHAR(50) NOT NULL,
first_name VARCHAR(50) NOT NULL,
INDEX (last_name, first_name)
);
এই ক্যোয়ারী সূচকের সুবিধা নেবে:
SELECT last_name, first_name FROM person
WHERE last_name = "John" AND first_name LIKE "J%"
তবে নিম্নলিখিতটি তা মানবে না
SELECT last_name, first_name FROM person WHERE first_name = "Constantine"
কারণ আপনি first_nameপ্রথমে কলামটি অনুসন্ধান করছেন এবং এটি সূচকের বামতম কলাম নয়।
এই শেষ উদাহরণটি আরও খারাপ:
SELECT last_name, first_name FROM person WHERE first_name LIKE "%Constantine"
কারণ এখন, আপনি সূচীর সবচেয়ে ডানদিকের ক্ষেত্রের সবচেয়ে অংশের সাথে তুলনা করছেন।
হ্যাশ সূচক
এটি একটি আলাদা সূচক প্রকার যা দুর্ভাগ্যক্রমে, কেবল মেমরি ব্যাকএন্ড সমর্থন করে। ফাস্ট কিন্তু পূর্ণ লুক-, যার মানে আপনি এটি ব্যবহার না পারেন, অপারেশন পছন্দের কেবল দরকারী এটা এর বাজ >, <বা LIKE।
যেহেতু এটি কেবল স্মৃতি ব্যাকএন্ডের জন্য কাজ করে, আপনি সম্ভবত এটি প্রায়শই ব্যবহার করবেন না। প্রধান মুহূর্তে আমি এখনই ভাবতে পারি এটি হ'ল যা আপনি মেমোরিতে একটি অস্থায়ী টেবিল তৈরি করে অন্য ফলাফল থেকে একটি ফলাফলের সেট নিয়ে হ্যাশ সূচকগুলি ব্যবহার করে এই অস্থায়ী টেবিলটিতে প্রচুর অন্যান্য নির্বাচন সম্পাদন করেন।
আপনার যদি একটি বড় VARCHARক্ষেত্র থাকে, আপনি একটি বি-ট্রি ব্যবহার করার সময়, একটি অন্য কলাম তৈরি করে এবং এতে বড় মানের একটি হ্যাশ সংরক্ষণ করে একটি হ্যাশ সূচকের ব্যবহার "অনুকরণ" করতে পারেন। ধরা যাক আপনি কোনও ক্ষেত্রে একটি url সঞ্চয় করছেন এবং মানগুলি বেশ বড়। আপনি যেকোন একটি পূর্ণসংখ্যার ক্ষেত্রও তৈরি করতে এবং ইউআরএল সন্নিবেশ করানোর সময় url_hashহ্যাশ ফাংশনের মতো CRC32বা অন্য কোনও হ্যাশ ফাংশন ব্যবহার করতে পারেন। এবং তারপরে, যখন এই মানটির জন্য আপনাকে জিজ্ঞাসা করতে হবে, আপনি এর মতো কিছু করতে পারেন:
SELECT url FROM url_table WHERE url_hash=CRC32("http://gnu.org");
উপরের উদাহরণ সহ সমস্যাটি হ'ল যেহেতু CRC32ফাংশনটি বেশ ছোট হ্যাশ উত্পন্ন করে, আপনি হ্যাশ মানগুলিতে অনেকগুলি সংঘর্ষের সাথে শেষ হবেন। আপনার যদি সঠিক মানগুলির প্রয়োজন হয় তবে আপনি নীচের কাজগুলি করে এই সমস্যাটি সমাধান করতে পারেন:
SELECT url FROM url_table
WHERE url_hash=CRC32("http://gnu.org") AND url="http://gnu.org";
এমনকি সংঘর্ষের সংখ্যাটি উচ্চ কারণ সত্ত্বেও জিনিসগুলি হ্যাশ করার পক্ষে মূল্য রয়েছে আপনি বারবার হ্যাশগুলির বিরুদ্ধে কেবল দ্বিতীয় তুলনা (স্ট্রিং এক) সম্পাদন করবেন।
দুর্ভাগ্যক্রমে, এই কৌশলটি ব্যবহার করে, আপনাকে urlক্ষেত্রটির সাথে তুলনা করতে এখনও টেবিলটি চাপতে হবে।
শেষ করি
আপনি যখনই অপ্টিমাইজেশনের বিষয়ে কথা বলতে চান প্রতিটি বিষয় বিবেচনা করতে পারেন:
পূর্ণসংখ্যার তুলনা স্ট্রিং তুলনার চেয়ে অনেক দ্রুত। এটিতে হ্যাশ সূচকটির অনুকরণ সম্পর্কে উদাহরণ সহ চিত্রিত করা যেতে পারে InnoDB।
হতে পারে, কোনও প্রক্রিয়াতে অতিরিক্ত পদক্ষেপ যুক্ত করা এটি দ্রুততর করে তোলে, ধীর নয়। এটি সত্য দ্বারা চিত্রিত করা যেতে পারে যে আপনি SELECTএকটিটিকে দুটি ধাপে বিভক্ত করে নতুনটিকে তৈরি করা মেমরি টেবিলের মধ্যে প্রথম এক স্টোরের মান তৈরি করে এবং তারপরে এই দ্বিতীয় সারণীতে ভারী প্রশ্নগুলি চালিয়ে যেতে পারেন।
মাইএসকিউএল এর অন্যান্য সূচীগুলিও রয়েছে, তবে আমি মনে করি যে বি + ট্রি একটি সবচেয়ে বেশি ব্যবহৃত হয় এবং হ্যাশটি জানা ভাল জিনিস তবে আপনি মাইএসকিউএল ডকুমেন্টেশনে অন্যগুলি খুঁজে পেতে পারেন ।
আমি আপনাকে "হাই পারফরম্যান্স মাইএসকিউএল" বইটি পড়ার জন্য উচ্চ প্রস্তাব দিচ্ছি, উপরের উত্তরটি অবশ্যই সূচকগুলি সম্পর্কে এর অধ্যায়ের উপর ভিত্তি করে ছিল।
