InnoDB indexes B+trees ਹੁੰਦੇ ਹਨ: balanced trees ਜਿੱਥੇ ਹਰ leaf ਇੱਕੋ depth ਉੱਤੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ range scans ਲਈ leaves ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ lookup O(log n) ਹੈ — ਵੱਡੀਆਂ tables ਉੱਤੇ ਵੀ ਮੁੱਠੀ ਭਰ page reads।
ਇੱਕ composite index rows ਨੂੰ ਪਹਿਲਾਂ ਨਾਲ, ਫਿਰ , ਫਿਰ ਨਾਲ sort ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਨੂੰ ਸਿਰਫ਼ columns ਦੇ ਇੱਕ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ: , , ਜਾਂ — ਪਰ ਇਕੱਲੇ ਲਈ ਜਾਂ ਲਈ , ਕਿਉਂਕਿ ਜਦੋਂ ਤੱਕ fix ਨਹੀਂ ਹੁੰਦਾ ਉਹ columns sorted ਨਹੀਂ ਹੁੰਦੇ।
(a, b, c)abca(a, b)(a, b, c)b(b, c)aCREATE INDEX idx_abc ON events (user_id, status, created_at);
-- USES the index (leftmost prefix, range on the last column)
SELECT * FROM events
WHERE user_id = 7 AND status = 'open' AND created_at > '2026-01-01';
-- Does NOT use it: skips the leftmost column
SELECT * FROM events WHERE status = 'open';
Columns ਨੂੰ most-selective / equality-first ਦੇ ਹਿਸਾਬ ਨਾਲ ਕ੍ਰਮਬੱਧ ਕਰੋ, range column ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ: ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ range (>, BETWEEN) 'ਤੇ ਪਹੁੰਚ ਜਾਂਦੇ ਹੋ, ਉਸ ਤੋਂ ਬਾਅਦ ਦੇ columns seeking ਲਈ ਨਹੀਂ ਵਰਤੇ ਜਾ ਸਕਦੇ।
ਜੇ ਇੱਕ index ਵਿੱਚ ਹਰ column ਹੋਵੇ ਜੋ query ਪੜ੍ਹਦੀ ਹੈ, InnoDB ਇਕੱਲੇ index ਤੋਂ ਹੀ ਜਵਾਬ ਦੇ ਦਿੰਦਾ ਹੈ — clustered index ਵੱਲ ਵਾਪਸ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ। EXPLAIN Using index ਦਿਖਾਉਂਦਾ ਹੈ।
CREATE INDEX idx_cover ON events (user_id, status, id);
EXPLAIN SELECT id FROM events WHERE user_id = 7 AND status = 'open';
-- Extra: Using index <- covering, no clustered-index lookup
Composite ਅਤੇ covering indexes ਉਹ ਤਰੀਕਾ ਹਨ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਹੌਲੀ multi-condition query ਨੂੰ ਇੱਕੋ index seek ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹੋ। column ਦਾ ਕ੍ਰਮ ਗ਼ਲਤ ਕਰਨਾ — ਜਾਂ ਇਹ ਉਮੀਦ ਕਰਨਾ ਕਿ ਦੂਜੇ column ਉੱਤੇ ਇੱਕ query index ਵਰਤੇਗੀ — ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਇੱਕ index ਜੋ "ਮੌਜੂਦ" ਹੈ ਫਿਰ ਵੀ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ