EXPLAIN optimizer ने निवडलेला plan दाखवते — तो प्रत्येक टेबल कसे access करेल — query न चालवता. Indexes वापरले जात आहेत आणि थोड्याच rows तपासल्या जातात याची खात्री करण्यासाठी तुम्ही ते वाचता.
EXPLAIN optimizer ने निवडलेला plan दाखवते — तो प्रत्येक टेबल कसे 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 आधीच sort होऊन बाहेर येतात — filesort नाहीसा होतो.
अंदाज चुकीचा असलेली प्रकरणे पकडण्यासाठी प्रत्यक्ष timing आणि row counts देखील पाहण्यासाठी EXPLAIN ANALYZE (MySQL 8) वापरा.
EXPLAIN हाच मार्ग आहे ज्याने तुम्ही अंदाज बांधण्याऐवजी पुराव्याचा वापर करता. type: ALL, प्रचंड rows, किंवा Using filesort ओळखल्याने तुम्हाला नेमके कुठे index गहाळ आहे हे कळते — "page slow आहे" पासून एका नेमक्या fix पर्यंतचा सर्वात जलद मार्ग.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या