Query plan — database engine SQL so‘rovini bajarish uchun tanlagan fizik operatorlar va ularning ketma-ketligi. U qaysi jadval qanday o‘qilishi, joinlar qaysi usulda bajarilishi, filter va sort qayerda qo‘llanishi hamda taxminan qancha resurs sarflanishini ko‘rsatadi.
Mantiqiy so‘rovdan fizik bajarilishga
SQL foydalanuvchi istagan natijani deklarativ tarzda ifodalaydi. Query optimizer shu natijaga olib keladigan ko‘plab ekvivalent yo‘llardan birini tanlaydi. Masalan, jadvalni to‘liq ketma-ket o‘qish, B-tree index orqali kerakli satrlarni topish yoki bitmap index natijalarini birlashtirish mumkin.
Plan odatda daraxt sifatida tasvirlanadi. Pastki operatorlar ma’lumotni o‘qiydi, yuqoridagilar filterlaydi, join qiladi, aggregate yoki sort bajaradi. Yakuniy operator clientga result set beradi. Operator nomlari va ko‘rsatiladigan metrikalar PostgreSQL, MySQL, SQL Server, Oracle va boshqa tizimlarda farqlanadi.
Asosiy operatorlar
Scan operatori jadval yoki indexdan qatorlarni oladi. Nested loop, hash join va merge join ikki oqimni birlashtirishning turli usullaridir. Sort operatori ORDER BY, merge join yoki ayrim aggregate uchun kerak bo‘lishi mumkin. Hash aggregate guruhlarni xotiradagi hash tuzilmasida, sort aggregate esa tartiblangan oqimda hisoblaydi.
Plan parallel workerlar, partition pruning, materialization va subquery execution kabi bosqichlarni ham ko‘rsatishi mumkin. “Index ishlatilgan” degan bitta belgi plan yaxshi ekanini isbotlamaydi; indexdan juda ko‘p random row olish sequential scandan qimmatroq bo‘lishi mumkin.
Taxmin va haqiqiy o‘lchov
Oddiy EXPLAIN so‘rovni bajarmasdan optimizer bahosini ko‘rsatadi. EXPLAIN ANALYZE yoki mahsulotdagi muqobili so‘rovni amalda bajarib, real vaqt va qatorlar sonini qayd etadi. O‘zgartiruvchi UPDATE yoki DELETE uchun bunday tahlil haqiqiy ma’lumotni o‘zgartirishi mumkin; xavfsiz transaction va rollback talab etiladi.
Estimated rows bilan actual rows orasidagi katta farq noto‘g‘ri plan sababini ko‘rsatishi mumkin. Bunga eskirgan statistika, ustunlar o‘rtasidagi correlation, notekis qiymat taqsimoti yoki parametr qiymati sabab bo‘ladi. Faqat umumiy execution time emas, har operator necha marta ishlagani va qancha qator chiqargani tekshiriladi.
Cost va statistika
Optimizer cost birligi odatda millisekund emas; u CPU, sequential IO va random IO kabi ichki koeffitsiyentlardan tuzilgan nisbiy bahodir. Jadval hajmi, distinct qiymatlar, histogram va null ulushi selectivityni taxmin qilishga yordam beradi. Statistika yangilanmasa optimizer mavjud bo‘lmagan yoki noto‘g‘ri taqsimotga tayangan holda qaror qiladi.
Prepared statementlarda generic va parameter-specific plan farqi muhim bo‘lishi mumkin. Kam uchraydigan qiymat uchun index scan, juda ko‘p uchraydigan qiymat uchun sequential scan ma’qul. Bitta cached plan barcha parametrlar uchun teng samarali bo‘lmasligi mumkin.
Tahlil qilish tartibi
Avval sekin so‘rovning aynan productionga yaqin parametr, schema va ma’lumot taqsimotida olingan plani ko‘riladi. Eng katta vaqt sarflagan operator, kutilmagan ko‘p qator, diskka spill, takroriy loop va partition pruning yo‘qligi aniqlanadi. Keyin so‘rov, index, statistika yoki schema bo‘yicha eng kichik asosli o‘zgarish sinov qilinadi.
Plan vaqt o‘tishi bilan data hajmi va versiya yangilanishi sabab o‘zgaradi. Shuning uchun muhim querylarning latency va plan fingerprintlari kuzatiladi. Plan hint yoki majburiy index oxirgi chora bo‘lib, kelajakdagi optimizer yaxshilanishini to‘sishi mumkin.
Bog‘liq tushunchalar
Query optimizer, EXPLAIN, Database statistics, Index scan, Sequential scan, Join algorithm, Cardinality estimation, Execution plan