EXPLAIN وہ plan دکھاتی ہے جو optimizer نے منتخب کیا — یہ ہر table تک کیسے پہنچے گی — query چلائے بغیر۔ آپ اسے یہ تصدیق کرنے کے لیے پڑھتے ہیں کہ indexes استعمال ہو رہی ہیں اور کم rows جانچی جا رہی ہیں۔
EXPLAIN وہ plan دکھاتی ہے جو optimizer نے منتخب کیا — یہ ہر table تک کیسے پہنچے گی — query چلائے بغیر۔ آپ اسے یہ تصدیق کرنے کے لیے پڑھتے ہیں کہ indexes استعمال ہو رہی ہیں اور کم rows جانچی جا رہی ہیں۔
const / eq_ref / ref (index lookups، اچھا) → range → index (full index scan) → ALL (full table scan، خطرے کی گھنٹی)۔NULL = کوئی نہیں)۔Using index (covering، بہترین)، Using filesort / Using temporary (memory میں یا disk پر sorting/grouping — اکثر 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 rows کے ایک ALL scan کو 30 کے ایک ref seek میں بدل دیا، اور چونکہ created_at دوسرا column ہے، rows پہلے سے sorted نکلتی ہیں — filesort غائب ہو جاتا ہے۔
اصل timing اور row counts بھی دیکھنے کے لیے EXPLAIN ANALYZE (MySQL 8) استعمال کریں، تاکہ اُن صورتوں کو پکڑا جا سکے جہاں تخمینہ غلط ہو۔
EXPLAIN وہ طریقہ ہے جس سے آپ اندازے کی جگہ ثبوت رکھ لیتے ہیں۔ type: ALL، ایک بہت بڑا rows، یا Using filesort دیکھنا آپ کو ٹھیک ٹھیک بتاتا ہے کہ کہاں index غائب ہے — "page سست ہے" سے ایک ہدف شدہ حل تک کا تیز ترین راستہ۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں