Covering index — ma’lum queryning filter, join, sorting va natija ustunlarining barchasi indeks ichida mavjud bo‘lgan indeksdir. Database jadvalning asosiy data page’lariga murojaat qilmasdan yoki juda kam murojaat bilan javob qaytara oladi. “Covering” indeksning mutlaq turi emas; u aynan bir queryga nisbatan baholanadi.
Qoplash sharti
Quyidagi query customer_id bo‘yicha qidirib, so‘nggi sana tartibida status va totalni qaytaradi:
SELECT created_at, status, total
FROM orders
WHERE customer_id = 42
ORDER BY created_at DESC
LIMIT 20;
(customer_id, created_at) INCLUDE (status, total) indeksi search va sort kalitlarini B-tree kalitida, natija fieldlarini leaf payload’da saqlashi mumkin. INCLUDE ustunlari tartibni belgilamaydi va predicate uchun odatdagi leading key kabi ishlamaydi.
Index-only scan
Covering indeks executor uchun index-only scan imkonini beradi. Clustered indeksli tizimlarda secondary index leaf’i primary keyni ham o‘z ichiga olishi mumkin. MVCC tizimida row visibilityni tekshirish uchun baribir heapga murojaat talab qilinishi mumkin.
PostgreSQL visibility map page’dagi barcha tuplelar barcha transactionlarga ko‘rinishini ko‘rsatsa heap fetchni tashlaydi. Tez-tez yangilanadigan table’da bitlar tozalanib, covering indeks kutilganidan kam foyda berishi mumkin. Vacuum holati plan natijasi bilan birga ko‘riladi.
Kalit va INCLUDE
Filter va sortingda ishlatiladigan ustunlar key qismiga kiradi. Faqat natijani qaytarish uchun kerak bo‘lgan fieldlar INCLUDE qismiga joylanadi. Bu key width va ayrim engine limitlarini boshqaradi. Unique indeksda odatda noyoblik faqat key ustunlariga qo‘llanadi, included fieldlarga emas.
Hamma ustunni qo‘shib yuborish indeksni table nusxasiga aylantiradi. Katta text, JSON yoki tez-tez o‘zgaradigan field indeks leaf’ini kengaytirib, cache zichligini kamaytiradi. Queryga real zarur fieldlar tanlanadi.
Write xarajati
Included column o‘zgarsa search key o‘zgarmasa ham indeks entry yangilanishi mumkin. Bu WAL, page split va replication hajmini oshiradi. Ayrim database optimizatsiyalari indexed fieldlar o‘zgarmagan update’da yengilroq yo‘l ishlatadi; INCLUDE ro‘yxati bunday imkoniyatni cheklashi mumkin.
Read-heavy endpointdagi millisekund tejash write-heavy table uchun katta umumiy xarajat keltirishi mumkin. Query chastotasi, row width va update rate bilan benchmark qilinadi.
Composite tartib
Covering bo‘lish queryni tez topishni avtomatik anglatmaydi. (created_at, customer_id, status, total) barcha fieldlarni saqlasa ham customer bo‘yicha qidiruv uchun noto‘g‘ri leading key bo‘lishi mumkin. Search prefix, range va sorting talabi avval, qoplash keyin ko‘riladi.
Bir necha o‘xshash query uchun bitta indeks qoplash kompromissini beradi. Har queryga alohida keng indeks yaratish write va storage xarajatini ko‘paytiradi. Existing indekslar prefix va INCLUDE jihatidan takrorlanishi tekshiriladi.
Diagnostika
EXPLAIN ANALYZE actual plan, heap fetch, buffer hit va sort operationni ko‘rsatadi. Index-only scan tanlanmasa statistika, visibility, type cast va query projection tekshiriladi. Optimizer ba’zan table kichik bo‘lgani uchun sequential scan’ni baribir arzon deb topadi.
Indeks usage counteri foydali, lekin server restartda reset bo‘lishi mumkin. Kam ishlatiladigan indeks muhim oylik reportga xizmat qilishi ehtimoli bor. Olib tashlashdan oldin workload davri va query catalog ko‘riladi.
Schema permissioni ham covering natijani o‘zgartirmaydi: indeksda sensitive field mavjudligi user uni o‘qiy olishini anglatmaydi. Database column permission va row policy’ni queryda tekshiradi. Physical backup yoki low-level diagnostic indeks page’larini ko‘ra olishi mumkin, shu sabab encryption va administrator access table data bilan bir xil darajada himoyalanadi.
Bog‘liq tushunchalar
Index-only scan, Composite index, INCLUDE column, Query optimizer, MVCC, Visibility map, Database index