एक index एक अलग, sorted data structure है (InnoDB में एक B-tree) जो MySQL को पूरी table को scan किए बिना rows खोजने देता है। इसके बिना, एक lookup हर row को पढ़ता है (एक full table scan); इसके साथ, यह कुछ ही चरणों में एक tree में चलता है।
InnoDB में table स्वयं primary key index होती है — एक clustered index। Rows भौतिक रूप से primary-key क्रम में store होती हैं, इसलिए primary key lookup सीधे पूरी row पर पहुँच जाता है।
एक secondary index अन्य column(s) पर keyed एक अलग B-tree है। इसके leaf nodes indexed value और primary key को store करते हैं, इसलिए किसी secondary index का उपयोग अक्सर row के बाकी हिस्से को लाने के लिए एक दूसरे lookup ("clustered index पर वापस") की लागत लेता है।
CREATE TABLE users (
id INT PRIMARY KEY, -- clustered: rows stored in id order
email VARCHAR(255),
city VARCHAR(80)
);
CREATE INDEX idx_city ON users (city); -- secondary B-tree on city
-- Fast: walks idx_city, then primary key for the rest of each row
SELECT * FROM users WHERE city = 'Hanoi';
-- Slow: no index on email -> full table scan
SELECT * FROM users WHERE email = '[email protected]';
Indexes reads को तेज़ करते हैं लेकिन हर INSERT/UPDATE/DELETE को उन्हें भी update करना पड़ता है, और वे disk लेते हैं। उन्हीं columns को index करें जिन पर आप वास्तव में filter, join या sort करते हैं — हर column को नहीं।
Indexes query speed पर सबसे बड़ा lever हैं: 3 tree nodes पढ़ने और दस लाख rows scan करने के बीच का अंतर। यह जानना कि InnoDB primary key पर cluster करता है, यह भी समझाता है कि एक छोटी, monotonic key (जैसे AUTO_INCREMENT) inserts और हर secondary index को क्यों दुबला रखती है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें