Index ni muundo wa data (mara nyingi B-tree) unaoiruhusu hifadhidata kupata safu kwa haraka bila kuchanganua jedwali zima — kama index ya kitabu. Huongeza kasi kwa kiasi kikubwa kwa utafutaji, vichujio, joins, na upangaji kwenye safuwima zilizoorodheshwa (indexed), kwa gharama ya hifadhi ya ziada na uandishi wa polepole zaidi.
users email ;
INDEX idx_users_email users(email);
Bila index, hifadhidata hufanya full table scan (kukagua kila safu). Ikiwa na index, husafiri kupitia B-tree kupata safu zinazolingana kwa muda wa logariti — tofauti kati ya kuchanganua mamilioni ya safu na utafutaji wa machache.
✓ Columns in WHERE clauses (frequently filtered)
✓ Columns used in JOINs (foreign keys especially)
✓ Columns in ORDER BY (sorting can use the index)
✓ Columns with high SELECTIVITY (many distinct values — email, id)
✓ Primary keys (auto-indexed) and unique constraints
✗ Columns rarely queried — wasted storage and write overhead
✗ Small tables — a full scan is already fast; an index adds no benefit
✗ Low-selectivity columns (e.g. a boolean with 2 values) — index barely helps
✗ Write-heavy columns — EVERY INSERT/UPDATE/DELETE must also update the indexes
→ too many indexes SLOW DOWN writes significantly
Index hazipatikani bure: hutumia hifadhi na hupunguza kasi ya uandishi (kila mabadiliko lazima yasasishe index). Kuwa na index nyingi kupita kiasi huumiza utendaji wa uandishi.
CREATE INDEX idx_users_country_name ON users(country, name); -- COMPOSITE (multi-column)
-- helps WHERE country = ? AND name = ?, and WHERE country = ? (leftmost prefix)
-- but NOT WHERE name = ? alone (order matters!)
CREATE UNIQUE INDEX ... -- enforces uniqueness
-- also: partial indexes, covering indexes, GIN/GiST (Postgres) for special data
Index ni mojawapo ya mada muhimu zaidi katika utendaji wa hifadhidata — ni zana kuu ya kufanya maswali kuwa ya haraka, na kuelewa lini na jinsi ya kuzitumia ni maarifa muhimu kwa yeyote anayefanya kazi na hifadhidata kwa kiwango kikubwa.
Thamani kuu ni kubwa: bila index, maswali yanayochuja, yanayounganisha, au yanayopanga kwenye safuwima yanahitaji full table scans (kukagua kila safu — polepole sana kadiri data inavyoongezeka), wakati index huzigeuza haya kuwa utafutaji wa haraka wa logariti — mara nyingi tofauti kati ya swali linalochukua milisekunde dhidi ya sekunde au dakika.
Kuelewa lini uweke index (safuwima za WHERE zinazochujwa mara kwa mara, safuwima za JOIN/foreign-key, safuwima za ORDER BY, safuwima zenye selectivity ya juu) ni muhimu kwa utendaji wa maswali.
Ni muhimu vivyo hivyo kuelewa uwiano wa faida na hasara na lini USIWEKE index: index hutumia hifadhi na, kwa umuhimu, hupunguza kasi ya uandishi (kila INSERT/UPDATE/DELETE lazima isasishe index zote), hivyo kuwa na index nyingi kupita kiasi huumiza utendaji wa uandishi, na index huongeza thamani ndogo kwenye jedwali ndogo au safuwima zenye selectivity ya chini.
Usawa huu — kuweka index kwa kile kinachoulizwa bila kuweka index kupita kiasi — ni ujuzi muhimu.
Kujua kuhusu composite indexes (safuwima nyingi, ambapo mpangilio wa safuwima ni muhimu kwa maswali yapi zinasaidia) hukamilisha maarifa ya kivitendo ya index.
Kwa kuwa utendaji wa maswali ni muhimu kwa programu halisi, na kwa kuwa kuweka index sahihi (index sahihi kwenye safuwima sahihi, kusawazisha kasi ya usomaji dhidi ya gharama ya uandishi na hifadhi) ni uboreshaji wenye athari kubwa zaidi wa hifadhidata, kufahamu vyema index — jinsi zinavyofanya kazi, lini zitumie, uwiano wa uandishi/hifadhi, na composite indexes — ni maarifa ya msingi, yenye thamani kubwa kwa hifadhidata zenye utendaji bora na mojawapo ya mada muhimu zaidi na zinazoulizwa sana za hifadhidata.