Fill factor — database index yoki table page’i yaratilganda uning necha foizi ma’lumot bilan to‘ldirilishini belgilaydigan storage sozlamasi. Qolgan bo‘sh joy kelajakdagi insert va update’lar uchun rezerv bo‘lib, page split yoki row migrationni kamaytirishi mumkin.
Indexdagi ma’no
B-tree index 100%ga yaqin qurilsa page soni va read I/O kam bo‘ladi. Lekin random keylar keyin o‘rtadagi to‘la page’ga kirsa tez page split yuz beradi. Masalan, 80 fill factor rebuild paytida leaf page’larda taxminan 20% bo‘sh joy qoldiradi.
Bu qiymat doimiy quota emas. Database keyingi insertda bo‘sh joydan foydalanadi va page to‘lishi mumkin. Delete page’ni bo‘shatadi. Fill factor ko‘pincha yangi page/buildga ta’sir qiladi, background process har page’ni belgilangan foizga qayta muvozanatlamaydi.
Table/heapda
PostgreSQL table fillfactori heap page’da update uchun joy qoldiradi. Yangi row version ayni page’da sig‘sa HOT update ehtimoli oshadi va index entrylari qayta yozilmaydi. Juda past qiymat table hajmi va scan qilinadigan page sonini ko‘paytiradi.
SQL Server kabi tizimlarda fill factor ko‘proq index leaf level build occupancy bilan bog‘liq. Vendorlar “pad index” yoki internal page sozlamasini alohida beradi. Bir mahsulot tavsiyasini boshqasiga aynan ko‘chirish mumkin emas.
Workload bo‘yicha tanlov
Read-only yoki bulk-load’dan keyin deyarli o‘zgarmaydigan index yuqori fill factordan foyda ko‘radi. Random insert/update ko‘p OLTP indexda pastroq qiymat splitni kamaytirishi mumkin. Monoton key bilan append qilinadigan indexda o‘rta page’lar o‘zgarmaydi, past fill factor keraksiz joy sarflashi mumkin.
Key distribution muhim. Sequential ID bilan birga update qilinadigan variable-length included column page’ni kengaytirishi mumkin. Composite indexda qaysi prefix bo‘yicha insert tarqalishi tahlil qilinadi.
Xarajat muvozanati
Past fill factor:
- page split va HOT bo‘lmagan update’ni kamaytirishi mumkin;
- index/table hajmini oshiradi;
- buffer cache’da kamroq logical row sig‘diradi;
- range va full scan uchun ko‘proq page o‘qitadi.
Yuqori fill factor buning teskarisini beradi, ammo write spike va fragmentation xavfini oshiradi. Optimal nuqta workload va storagega bog‘liq.
Qo‘llash
Sozlamani o‘zgartirish mavjud page’larni darhol qayta joylamasligi mumkin. Index rebuild/reorganize yoki table rewrite yangi layout yaratadi. Operatsiya lock, temporary storage, transaction log/WAL va replication lagga ta’sir qiladi.
Productionga oldin representative copy’da rebuild hajmi va vaqti o‘lchanadi. Online variant o‘qish/yozishni davom ettirishi mumkin, ammo qisqa schema lock va yuqori resource iste’moli qoladi.
O‘lchash
Page density, page split rate, index size, cache hit, logical read, update latency va WAL generation birga kuzatiladi. Faqat split countni kamaytirish uchun fill factorni pastlatish read performance’ni yomonlashtirishi mumkin.
PostgreSQLda HOT ratio, dead tuple va autovacuum; boshqa engine’da page fullness va fragmentation viewlari qo‘shimcha signal. Bir nechta asosiy indexga per-object qiymat berish global bir xil sozlamadan aniqroq.
Fill factor mavjud sahifalarga doimiy ravishda bo‘sh joyni qaytarib bermaydi; u ko‘pincha indeks yaratish yoki qayta qurish paytida qo‘llanadi. Keyingi yozuvlar bo‘shliqni egallaydi, shuning uchun davriy statistika dastlabki sozlamadan muhimroq bo‘lishi mumkin.
Bog‘liq tushunchalar
Page split, B-tree, Leaf page, HOT update, Index fragmentation, Buffer cache, Page density, Index rebuild