Index scan — database query executorining kerakli satrlarni topish uchun jadvalni boshidan oxirigacha o‘qish o‘rniga indeks strukturasidan foydalanish usulidir. B-tree indeksida executor kalit oralig‘iga tushib, mos entrylarni tartib bo‘yicha o‘qiydi va zarur bo‘lsa table rowlariga murojaat qiladi.
Oddiy index scan
Indeks entry odatda kalit va table row locatorini saqlaydi. Executor avval indeksdan locatorlarni topadi, keyin heap yoki clustered table’dan satrlarni oladi. Kam satr tanlanganda bu juda samarali. Ko‘p tarqoq satrda random page access sequential scan’dan qimmatlashadi.
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE customer_id = 42;
Plan estimated rows, actual rows, loop, buffer va vaqtni ko‘rsatishi mumkin. Estimate bilan actual katta farq qilsa statistics yoki column correlation tekshiriladi.
Index-only scan
Query uchun kerakli barcha fieldlar indeksda bo‘lsa executor heapga bormasdan javob berishi mumkin. PostgreSQL kabi MVCC tizimida row visibility indeksning o‘zida to‘liq bo‘lmasligi mumkin; visibility map page o‘zgarmaganini ko‘rsatsa heap fetch tashlanadi.
Covering indeks readni tezlashtiradi, lekin indeks hajmi va write overheadini oshiradi. SELECT * ko‘pincha index-only scan imkonini yo‘qotadi. Faqat kerakli columnlarni tanlash query contractini ham aniq qiladi.
Bitmap scan
Ko‘proq satr tanlanganda executor avval barcha row locatorlarni bitmapga yig‘ib, table page’larini tartibliroq o‘qishi mumkin. Bir nechta indeks bitmap AND yoki OR bilan birlashtiriladi. Bu random I/Oni kamaytiradi, ammo bitmap uchun xotira va alohida bosqich talab qiladi.
Bitmap zichlashsa lossy page belgilari ishlatiladi va table rowlarida predicate qayta tekshiriladi. Rows Removed by Index Recheck shuni ko‘rsatishi mumkin. Juda kam satrda oddiy scan, juda ko‘p satrda sequential scan afzal bo‘ladi.
Range va order
B-tree equality, range va prefixga mos tartiblangan scan beradi. ORDER BY indeks tartibiga mos bo‘lsa alohida sort kerak emas. LIMIT bilan executor birinchi natijalarni olgach to‘xtashi mumkin.
Direction backward bo‘lishi mumkin. Composite indeksda leading column va sort yo‘nalishi queryga mos bo‘ladi. Range predicate’dan keyingi ustunlar filter sifatida tekshirilishi, ammo scan chegarasini to‘liq toraytirmasligi mumkin.
Sargability
Predicate indeks qidiruviga aylantirilishi sargable deyiladi. created_at >= ? sargable, date(created_at) = ? esa oddiy indeksni ishlatmasligi mumkin. Range chegarasini asl column ustida yozish yoki expression index yaratish yechim bo‘ladi.
Type mismatch va implicit cast ham scan’ni to‘sishi mumkin. Text columnni integer parametr bilan solishtirish conversionni column tomonida bajarsa har entry uchun function ishlaydi. Parameter turi schema bilan mos yuboriladi.
Plan tanlash va cache
Optimizer index depth, expected row, page correlation va I/O cost asosida plan tanlaydi. Table cacheda bo‘lsa random access diskka qaraganda arzon. Cost setting hardwarega juda nomos bo‘lsa plan tanlovi buzilishi mumkin.
Indeks mavjudligi uning doim ishlatilishi kerakligini anglatmaydi. Query jadvalning katta qismini qaytarsa sequential scan to‘g‘ri tanlov. Force hint muammoni yashirishi mumkin; avval statistika, predicate va indeks dizayni tekshiriladi.
Lock va concurrency
Index scan MVCC snapshotiga mos rowlarni qaytaradi. SELECT ... FOR UPDATE ishlatilsa topilgan rowlar lock olinadi; indeks faqat topish yo‘lini tezlashtiradi, lock scope’ini o‘zgartirmaydi. Range predicate uchun ayrim engine phantomni cheklash maqsadida key-range yoki gap lock olishi mumkin. Uzoq scan ko‘p lock saqlab concurrent writerlarni kutkazadi, shu sabab transaction hajmi va isolation darajasi plan bilan birga tahlil qilinadi.
Bog‘liq tushunchalar
Database index, Sequential scan, Index-only scan, Bitmap index scan, Query plan, Sargability, B-tree