EXPLAIN optimizer যে plan বেছে নিয়েছে তা দেখায় — এটি প্রতিটি টেবিল কীভাবে access করবে — query না চালিয়েই। আপনি এটি পড়েন index ব্যবহৃত হচ্ছে এবং কম row পরীক্ষা করা হচ্ছে তা নিশ্চিত করতে।
EXPLAIN optimizer যে plan বেছে নিয়েছে তা দেখায় — এটি প্রতিটি টেবিল কীভাবে access করবে — query না চালিয়েই। আপনি এটি পড়েন index ব্যবহৃত হচ্ছে এবং কম row পরীক্ষা করা হচ্ছে তা নিশ্চিত করতে।
const / eq_ref / ref (index lookup, ভালো) → range → index (full index scan) → ALL (full table scan, বিপদসংকেত)।NULL = কোনোটি নয়)।Using index (covering, চমৎকার), Using filesort / Using temporary (memory বা disk-এ sort/group করা — প্রায়ই optimize করা যায়)।EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- +------+------+------+---------+--------+----------------+
-- | type | key | rows | Extra |
-- | ALL | NULL | 900k | Using where; Using filesort | <- scans everything, sorts
-- +------+------+------+---------+--------+----------------+
-- Add an index that covers the filter AND the sort order:
CREATE INDEX idx_cust_created ON orders (customer_id, created_at);
EXPLAIN SELECT * FROM orders WHERE customer_id = 42 ORDER BY created_at;
-- | type | key | rows | Extra |
-- | ref | idx_cust_created | 30 | Using where | <- seeks 30 rows, no filesort
index একটি 900k row-এর ALL scan-কে 30 row-এর একটি ref seek-এ পরিণত করেছে, এবং যেহেতু created_at দ্বিতীয় column, row-গুলো আগে থেকে sorted অবস্থায় বেরিয়ে আসে — filesort অদৃশ্য হয়ে যায়।
আনুমানিক হিসাব ভুল এমন ক্ষেত্র ধরতে actual timing ও row count দেখতে EXPLAIN ANALYZE (MySQL 8) ব্যবহার করুন।
EXPLAIN হলো যেভাবে আপনি অনুমানের বদলে প্রমাণ ব্যবহার করেন। type: ALL, বিশাল rows, বা Using filesort চিহ্নিত করা আপনাকে ঠিক কোথায় একটি index অনুপস্থিত তা বলে দেয় — "page-টা ধীর" থেকে একটি লক্ষ্যভিত্তিক সমাধান পর্যন্ত দ্রুততম পথ।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন