EXPLAIN वह plan दिखाता है जो optimizer ने चुना — यह हर table को कैसे access करेगा — query को चलाए बिना। आप इसे यह पुष्टि करने के लिए पढ़ते हैं कि indexes का उपयोग हो रहा है और कम rows की जाँच हो रही है।
EXPLAIN वह plan दिखाता है जो optimizer ने चुना — यह हर table को कैसे access करेगा — 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 गायब हो जाता है।
actual timing और row counts भी देखने के लिए EXPLAIN ANALYZE (MySQL 8) का उपयोग करें, जो उन मामलों को पकड़ता है जहाँ अनुमान गलत है।
EXPLAIN वह तरीका है जिससे आप अनुमान लगाने की जगह साक्ष्य रखते हैं। type: ALL, एक विशाल rows, या Using filesort को पहचानना आपको ठीक-ठीक बताता है कि कहाँ एक index गायब है — "page slow है" से एक लक्षित समाधान तक का सबसे तेज़ रास्ता।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें