Partial index

Partial index — jadvalning faqat berilgan predicate’ga mos satrlarini indekslaydigan database indeksidir. U butun jadvalni qamrab olmaydi. Tez-tez so‘raladigan kichik subset uchun indeks hajmi va write xarajatini kamaytirib, queryni tezlashtiradi.

Predicate

Index definitsiyasidagi WHERE sharti qaysi satrlar indeksga kirishini belgilaydi:

CREATE INDEX pending_jobs_idx
ON jobs (priority, created_at)
WHERE status = 'pending';

Bu indeks pending joblarni priority bo‘yicha olishga mos. Completed satrlar indeksda yo‘q, shu sabab worker queue querysi kichik strukturani scan qiladi. Status pending’dan completed’ga o‘zgarganda indeks entry o‘chiriladi.

Query predicate mosligi

Optimizer query sharti index predicate’ni mantiqan kafolatlashini isbotlashi kerak. WHERE status = 'pending' aniq mos. Murakkab function, parameter yoki boshqa yozilish matematik jihatdan teng bo‘lsa ham optimizer uni tanimasligi mumkin.

Prepared statementda status = $1 qiymati plan tuzilayotganda noma’lum bo‘lsa partial indeks ishlatilmasligi ehtimoli bor. Custom va generic plan xatti-harakati enginega bog‘liq. Query plan real parametr va production statistikasida tekshiriladi.

Asosiy qo‘llanishlar

Partial index quyidagi holatlarda foydali:

• soft delete qilingan satrlarni chiqarib tashlash;
• faqat processed_at IS NULL navbat elementlarini indekslash;
• kam uchraydigan error yoki active holatni qamrash;
• null bo‘lmagan optional fieldlar uchun indeks yaratish;
• ma’lum tenant yoki data segmentiga vaqtinchalik tezlik berish.

Predicate juda keng bo‘lsa oddiy indeksdan kam farq qiladi. Juda tor bo‘lsa kam queryga xizmat qiladi. Subset hajmi va query chastotasi birga o‘lchanadi.

Partial unique index

Noyoblik ham faqat subsetga qo‘llanishi mumkin. Masalan, har userda faqat bitta active subscription bo‘lishi:

CREATE UNIQUE INDEX one_active_subscription
ON subscriptions (user_id)
WHERE ended_at IS NULL;

Bu application checkiga qaraganda parallel transactionlarda ishonchliroq. ended_at nullability va barcha update yo‘llari constraint bilan mos bo‘lishi kerak.

Statistik va plan tanlovi

Index kichik bo‘lgani uchun cachega yaxshi sig‘adi va maintenance arzonlashadi. Biroq subset ichida query ko‘p satr qaytarsa sequential scan baribir arzon bo‘lishi mumkin. Optimizer index entry, heap fetch va sorting xarajatini hisoblaydi.

Predicate ustunidagi data taqsimoti o‘zgarsa indeks foydasi ham o‘zgaradi. Masalan, pending joblar tiqilib qolib jadvalning yarmiga aylansa oldingi kichik indeks endi katta bo‘ladi. Monitoring indeks hajmi va queue holatini kuzatadi.

Cheklov va maintenance

Predicate odatda immutable yoki barqaror expressionlardan tuzilishi kerak. Hozirgi vaqtga bog‘liq WHERE expires_at > now() kabi shart indeks a’zoligini vaqt o‘tishi bilan o‘z-o‘zidan yangilamaydi. Vaqt oynasi uchun partitioning yoki explicit status field qo‘llanadi.

Schema migration predicate’dagi columnni rename yoki type change qilsa dependency tekshiriladi. Index usage statistikasi nol bo‘lsa ham kam uchraydigan muhim incident queryga xizmat qilishi mumkin; olib tashlashdan oldin workload va maqsad hujjati ko‘riladi.

Multi-tenant misoli

Bitta yirik tenant uchun maxsus partial indeks yaratish qisqa muddatli hotspotni tezlashtirishi mumkin, ammo har tenant uchun alohida indeks schema va planningni boshqarib bo‘lmas holga olib keladi. Umumiy composite indeks yoki partitioning ko‘proq masshtablanadi. Tenant-specific indeks zarur bo‘lsa uning owneri, expiry sanasi va usage mezoni qayd etiladi; aks holda vaqtinchalik optimizatsiya doimiy write xarajatiga aylanadi.

Bog‘liq tushunchalar

Database index, Index predicate, Unique index, Query optimizer, Soft delete, Selectivity, Prepared statement