Query optimizer — SQL so‘rovining ma’nosini saqlagan holda uni bajarish uchun ehtimoliy rejalardan nisbatan arzonini tanlaydigan database komponenti. U join tartibi, access path, aggregate usuli, parallelizm va boshqa fizik operatorlarni ma’lumot statistikasi hamda cost modeli asosida baholaydi.
Optimallashtirish bosqichlari
Parser SQL matnini sintaktik tuzilmaga aylantiradi, semantic analysis esa jadval, ustun, tip va huquqlarni tekshiradi. Keyin rewrite bosqichi viewlarni ochishi, constant expressionlarni soddalashtirishi yoki mantiqan ekvivalent transformatsiyalarni qo‘llashi mumkin. Optimizer hosil bo‘lgan relational ifoda uchun fizik query plan izlaydi.
Predicate pushdown filterlarni ma’lumot manbasiga yaqinroq qo‘llab, keyingi operatorlarga keladigan satrlarni kamaytiradi. Projection pruning kerak bo‘lmagan ustunlarni erta olib tashlaydi. Join elimination natijaga ta’sir qilmaydigan joinni constraintlar asosida bekor qilishi mumkin. Har transformatsiya SQLning NULL, duplicate va outer join semantikasini saqlashi shart.
Cost asosidagi tanlov
Cost-based optimizer har variantning taxminiy CPU, IO, xotira va tarmoq xarajatini hisoblaydi. Selectivity — shartdan keyin satrlarning qancha qismi qolishini bildiradi. Buni topish uchun row count, distinct qiymatlar, histogram va boshqa statistika ishlatiladi.
Joinlar soni oshganda barcha tartiblarni ko‘rib chiqish kombinator jihatdan juda qimmatlashadi. Optimizer dynamic programming, pruning, heuristic yoki genetik qidiruv kabi usullar bilan search spaceni cheklaydi. Shu sabab nazariy eng yaxshi reja har doim topilmasligi mumkin, ammo optimallashtirishning o‘zi ham maqbul vaqtda tugashi kerak.
Cardinality estimation
Plan sifati ko‘pincha har operator chiqargan satrlar soni taxminiga bog‘liq. Ikki ustun mustaqil deb qabul qilinsa, aslida ular kuchli bog‘liq bo‘lgan ma’lumotda baho xato chiqadi. Masalan, shahar va pochta indeksi o‘rtasidagi correlation oddiy alohida statistikada yo‘qoladi. Ayrim tizimlar extended statistics bilan bunday bog‘liqlikni qayd eta oladi.
Eskirgan statistika, parametr yashirilishi, expression ustida filter va juda notekis data taqsimoti ham estimation xatosiga sabab bo‘ladi. Estimated va actual rowsni query planda solishtirish muammoni aniqlashning asosiy usullaridan biridir.
Parametr va reja keshi
Parameterized query compilation natijasini qayta ishlatishga imkon beradi. Lekin qiymatlar taqsimoti notekis bo‘lsa, birinchi yoki odatiy parametr uchun tanlangan plan boshqa qiymatga yomon tushishi mumkin. Bu holat mahsulotga qarab parameter sniffing, bind peeking yoki generic plan muammosi sifatida ko‘rinadi.
Recompile, plan variantlari yoki statistikani yaxshilash mumkin bo‘lgan yechimlardir. Har bir so‘rovga hint yozish esa optimizer erkinligini kamaytiradi va data o‘sganda eskiradigan qo‘lda boshqaruv yukini yaratadi.
Amaliy boshqaruv
Optimizerga “index bor” degan fikr bilan baho berilmaydi. Index selectivity, covering imkoniyati, write xarajati va real querylar bilan tahlil qilinadi. Plan o‘zgarishi database yangilanishi, schema migration, statistika yangilanishi yoki data hajmi ortishi bilan yuz berishi mumkin.
Muhim querylar uchun p95/p99 latency, o‘qilgan qatorlar, buffer hit, temporary spill va plan fingerprint kuzatiladi. Yaxshilash avval o‘lchanadi, productionga yaqin data bilan solishtiriladi va regression testi bilan himoyalanadi. Optimizer kuchli avtomatlashtirish vositasi, lekin noto‘g‘ri ma’lumot modeli yoki cheklanmagan so‘rovni har doim tuzatib bera olmaydi.
Optimizer qarori kuzatiladigan va qayta tekshiriladigan taxmindir.
Bog‘liq tushunchalar
Query plan, Cost model, Cardinality estimation, Database statistics, Predicate pushdown, Join order, Plan cache, Index