LEFT JOIN yozdingiz, lekin u INNER JOIN bo'lib qoldi 🤦‍♂️
Bu — SQL suhbatlarida eng ko'p "yiqitadigan" xato.
Vazifa: har bir mijozni va uning yanvardagi buyurtmalari sonini chiqaring. Buyurtma bermaganlar ham ro'yxatda 0 bilan turishi kerak.

Ko'pchilik shunday yozadi 👇

SELECT c.name, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.created_at >= '2026-01-01'
GROUP BY c.name;

Natija: yanvarda buyurtma bermagan mijozlar umuman yo'qoladi.

Sababi oddiy:
LEFT JOIN avval o'ng jadvaldan mos qator topmasa, o.* ustunlarini NULL qilib qo'yadi. Keyin WHERE o.created_at >= ... ishga tushadi va o'sha NULL qatorlarni o'chirib tashlaydi. Ya'ni siz yozgan LEFT JOIN amalda INNER JOIN.

To'g'ri variant — filtrni ON ichiga olish 👇

SELECT c.name, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o
       ON o.customer_id = c.id
      AND o.created_at >= '2026-01-01'
GROUP BY c.name;

📌 Yodda tuting:
ON — join qilishdan oldin o'ng jadvalni filtrlaydi
WHERE — join tugagandan keyin butun natijani filtrlaydi
Va yana bir tuzoq: bu yerda COUNT(*) emas, COUNT(o.id) yozilgan. COUNT(*) buyurtmasi yo'q mijozga ham 1 deb ko'rsatadi, chunki NULL bo'lsa ham qator mavjud.

Shunga o'xshash 200+ masala 👉 sqlmaster.uz

Rasmiy kanal: @sqlmasteruz

Marhamat — fan-out (dublikat qatorlar) mavzusidagi post:

JOIN dan keyin summangiz 3 barobar oshib ketdimi? 📈
Hisobot yozdingiz, raqam boshliqqa ketdi, keyin ma'lum bo'ldi — savdo hajmi aslida uch barobar kam. Tanish holat.
Vazifa: har bir mijoz bo'yicha umumiy buyurtma summasi va sotib olingan mahsulotlar soni.

Ko'pchilik shunday yozadi 👇

SELECT c.name,
       SUM(o.amount)   AS jami_summa,
       SUM(i.quantity) AS mahsulotlar
FROM customers c
JOIN orders      o ON o.customer_id = c.id
JOIN order_items i ON i.order_id    = o.id
GROUP BY c.name;

Muammo: bitta buyurtmada 3 ta mahsulot bo'lsa, JOIN o'sha buyurtmani 3 marta takrorlaydi. Demak o.amount ham 3 marta qo'shiladi.
SUM(o.amount) = xato. SUM(i.quantity) = to'g'ri.
Ya'ni bitta so'rovda bir ustun to'g'ri, ikkinchisi noto'g'ri — shuning uchun ham bu xatoni payqash qiyin.

Sabab: JOIN 1:N munosabatda chap jadvalning qatorini ko'paytiradi (fan-out). Agar ikkita 1:N jadval qo'shsangiz — qatorlar ko'payib emas, ko'paytirilib ketadi (3 ta mahsulot × 2 ta to'lov = 6 qator).
Yechim: har bir darajani alohida agregatsiya qilib, keyin join qiling 👇

WITH ord AS (
    SELECT customer_id, SUM(amount) AS jami_summa
    FROM orders
    GROUP BY customer_id
),
itm AS (
    SELECT o.customer_id, SUM(i.quantity) AS mahsulotlar
    FROM orders o
    JOIN order_items i ON i.order_id = o.id
    GROUP BY o.customer_id
)
SELECT c.name, ord.jami_summa, itm.mahsulotlar
FROM customers c
LEFT JOIN ord ON ord.customer_id = c.id
LEFT JOIN itm ON itm.customer_id = c.id;

🔍 Tekshirish usuli: JOIN dan oldin va keyin COUNT(*) ni solishtiring. Qatorlar soni oshgan bo'lsa — join kaliti o'ng jadvalda unikal emas, demak summalaringizga ishonmang.
⚠️ SUM(DISTINCT o.amount) bilan "tuzatmang" — ikki mijozning summasi tasodifan teng bo'lsa, bittasi yo'qoladi.

Amaliyot 👉 sqlmaster.uz

Rasmiy kanal: @sqlmasteruz

#sql #roadmap

Amaliyot 👉 sqlmaster.uz

Rasmiy kanal: @sqlmasteruz

☕ Ertalabki savol

users jadvalida 100 ta qator bor. Ulardan 30 tasida phone ustuni NULL.

Shu so'rov nima qaytaradi? 👇

SELECT COUNT(*), COUNT(phone)
FROM users;

A) 100 va 100
B) 100 va 70
C) 70 va 70

Javobingizni izohda yozing — bugun 20:00 da tahlil qilamiz 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

⚠️ NOT IN sizni jimgina aldaydi

Vazifa: hech qachon buyurtma bermagan mijozlarni toping.

Ko'pchilik shunday yozadi 👇

SELECT name
FROM customers
WHERE id NOT IN (SELECT customer_id FROM orders);

Natija: bo'sh jadval. Bitta ham mijoz chiqmaydi, holbuki ular bor.

Sabab. orders.customer_id ustunida bitta NULL bo'lsa yetarli. id NOT IN (1, 2, NULL) ifodasi hech qachon TRUE bo'lmaydi — u UNKNOWN qaytaradi, chunki SQL «bu qiymat NULL ga teng emasmi?» degan savolga javob bera olmaydi. WHERE esa faqat TRUE qatorlarni o'tkazadi.

To'g'ri variant 👇

SELECT c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 FROM orders o
    WHERE o.customer_id = c.id
);

Yoki LEFT JOIN ... IS NULL orqali:

SELECT c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

📌 Qoida: NOT IN faqat ustun NOT NULL ekaniga ishonchingiz komil bo'lsa. Aks holda doim NOT EXISTS.

Bu tuzoq ish suhbatlarida ataylab so'raladi.

🎯 Endi amaliyot: Qora ro'yxatda bo'lmagan mijozlar (NULL tuzog'i)
Aynan shu tuzoq ustiga qurilgan masala. NOT EXISTS bilan yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki savol javobi: B — 100 va 70

COUNT(*) qatorlarni sanaydi — 100 ta.
COUNT(phone) esa faqat NULL bo'lmagan qiymatlarni sanaydi — 70 ta.

Bu farq hisobotlarda jimgina xato keltirib chiqaradi.

📊 Yodda tuting:
COUNT(*) — qatorlar soni
COUNT(ustun) — NULL bo'lmagan qiymatlar soni
COUNT(1) — COUNT(*) bilan bir xil, tezligi ham bir xil
COUNT(DISTINCT ustun) — takrorlanmaydigan qiymatlar

⚠️ Xuddi shu mantiq AVG va SUM ga ham tegishli:

SELECT AVG(salary) FROM employees;

Maoshi kiritilmagan (NULL) xodimlar o'rtachaga umuman qo'shilmaydi. Ularni nol deb hisoblamoqchi bo'lsangiz:

SELECT AVG(COALESCE(salary, 0)) FROM employees;

Ikki so'rov ikki xil raqam qaytaradi — qaysi biri to'g'ri ekanini siz hal qilasiz, baza emas.

💬 Shu xatoga duch kelganmisiz? Izohda yozing.

🎯 Endi amaliyot: O'rtacha: NULL larni hisobga olish
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🔢 SQL so'rovi siz yozgan tartibda bajarilmaydi

Siz SELECT dan boshlab yozasiz, baza esa boshqa tartibda ishlaydi:

1️⃣ FROM va JOIN — jadvallar birlashtiriladi
2️⃣ WHERE — qatorlar filtrlanadi
3️⃣ GROUP BY — guruhlanadi
4️⃣ HAVING — guruhlar filtrlanadi
5️⃣ SELECT — ustunlar tanlanadi, alias shu yerda paydo bo'ladi
6️⃣ ORDER BY — saralanadi
7️⃣ LIMIT — kesiladi

Shundan kelib chiqadigan uchta amaliy xulosa:

❌ WHERE da alias ishlatib bo'lmaydi — u hali mavjud emas:

SELECT price * 1.12 AS total
FROM products
WHERE total > 100;   -- xato!

✅ To'g'risi: WHERE price * 1.12 > 100

✅ ORDER BY da esa alias ishlaydi — u SELECT dan keyin bajariladi.

❌ WHERE ichida SUM() yozib bo'lmaydi — guruhlash hali bo'lmagan. Agregat bo'yicha filtr faqat HAVING da:

SELECT customer_id, SUM(amount) AS jami
FROM orders
WHERE status = 'paid'      -- qatorlarni filtrlaydi
GROUP BY customer_id
HAVING SUM(amount) > 1000000;  -- guruhlarni filtrlaydi

📌 Qoida: WHERE — guruhlashdan oldin, HAVING — keyin. Filtrni iloji boricha WHERE ga qo'ying: kamroq qator guruhlanadi, so'rov tezroq ishlaydi.

🎯 Endi amaliyot: HAVING ichida subquery
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki test javobi: NULL qatorlar chiqmaydi

SQL ikki qiymatli emas, uch qiymatli mantiq bilan ishlaydi: TRUE, FALSE va UNKNOWN.

NULL <> 'active' → UNKNOWN
NULL = NULL → UNKNOWN (ha, NULL o'ziga ham teng emas!)

WHERE esa faqat TRUE bo'lgan qatorlarni o'tkazadi. UNKNOWN — tashlab yuboriladi.

Yechimlar:

-- 1. Ochiq-oydin qo'shish
WHERE status <> 'active' OR status IS NULL

-- 2. NULL ni qiymatga aylantirish
WHERE COALESCE(status, 'none') <> 'active'

-- 3. PostgreSQL usuli
WHERE status IS DISTINCT FROM 'active'

Uchinchisi eng toza: IS DISTINCT FROM NULL ni oddiy qiymat kabi solishtiradi.

⚠️ Eng xavflisi shundaki, bunday so'rov xato bermaydi. Shunchaki qatorlar yo'qoladi — hisobotdagi raqam kamayadi, siz esa sezmaysiz.

💬 Sizning bazangizda qaysi ustunlar NULL bo'lishi mumkin? Bir tekshirib ko'ring 👇

🎯 Endi amaliyot: NULL: uch qiymatli mantiq tuzog'i
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: klassik intervyu savoli

Jadval: employees(id, name, department, salary)

Vazifa: har bir bo'limdagi eng yuqori maosh oladigan xodimni chiqaring. Bitta bo'limda bir xil maosh bilan ikki kishi bo'lsa — ikkalasi ham ro'yxatda bo'lsin.

SELECT ???
FROM employees
???

🎯 Bu savol ish suhbatlarida eng ko'p beriladigan uchlikdan biri. Kamida ikki xil yechimi bor.

✍️ O'z variantingizni izohda yozing — 20:00 da ikkala yechimni ham tahlil qilamiz 👇

🎯 Endi amaliyot: Har bo'limdagi eng yuqori maosh
Masala saytda ham bor — yozing, tizim javobingizni darhol tekshiradi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🪟 ROW_NUMBER, RANK, DENSE_RANK — farqi nimada?

Uchalasi ham qatorlarga raqam beradi, lekin teng qiymatlarda boshqacha yo'l tutadi.

Misol: ballar 100, 90, 90, 80

ROW_NUMBER() → 1, 2, 3, 4
Har qatorga noyob raqam. Teng bo'lsa ham farqlaydi (qaysi biri 2, qaysi biri 3 — tasodifiy, agar ORDER BY aniq bo'lmasa).

RANK() → 1, 2, 2, 4
Tenglar bir xil o'rin oladi, keyingi o'rin sakraydi. Sport natijalari shunday.

DENSE_RANK() → 1, 2, 2, 3
Tenglar bir xil o'rin oladi, sakrash yo'q.

SELECT
    name,
    score,
    ROW_NUMBER() OVER (ORDER BY score DESC) AS rn,
    RANK()       OVER (ORDER BY score DESC) AS rnk,
    DENSE_RANK() OVER (ORDER BY score DESC) AS drnk
FROM results;

PARTITION BY — guruh ichida sanash uchun:

ROW_NUMBER() OVER (
    PARTITION BY department
    ORDER BY salary DESC
)

Bu «har bo'lim ichida maosh bo'yicha tartiblab, 1 dan sanash» degani.

📌 Qaysi birini tanlash:
• dublikat o'chirish, «har guruhdan bittasi» → ROW_NUMBER
• «top 3», tenglar ham kirsin → DENSE_RANK
• haqiqiy reyting, o'rin sakrasin → RANK

🎯 Endi amaliyot: RANK va DENSE_RANK farqi
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki masala yechimi: har bo'limdagi eng yuqori maosh

1-usul: window funksiya (zamonaviy, tavsiya etiladi)

WITH ranked AS (
    SELECT name, department, salary,
           RANK() OVER (PARTITION BY department
                        ORDER BY salary DESC) AS r
    FROM employees
)
SELECT name, department, salary
FROM ranked
WHERE r = 1;

Bu yerda RANK ishlatildi, chunki shartda «bir xil maosh bo'lsa ikkalasi ham» deyilgan. ROW_NUMBER bo'lsa faqat bittasi chiqardi.

2-usul: korrelyatsion subquery (eski bazalarda ham ishlaydi)

SELECT name, department, salary
FROM employees e
WHERE salary = (
    SELECT MAX(salary)
    FROM employees
    WHERE department = e.department
);

Qaysi biri yaxshi? Odatda window — jadval bir marta o'qiladi. Subquery esa har qator uchun ichki so'rovni qayta bajarishi mumkin (index bo'lmasa ayniqsa og'ir).

❌ Eng ko'p uchraydigan xato:

SELECT name, department, MAX(salary)
FROM employees
GROUP BY department;   -- xato!

Bu yerda name qaysi xodimniki ekani noma'lum. PostgreSQL xato beradi, MySQL esa tasodifiy ism qaytaradi — bu yanada yomon, chunki so'rov «ishlaydi».

💬 Siz qaysi usulni yozgan edingiz?

🎯 Endi amaliyot: Ikkinchi eng yuqori maosh
Shu mantiqning davomi — intervyu klassikasi 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🔁 DISTINCT bilan «tuzatish» — eng qimmat odat

So'rov dublikat qaytardi. Ko'pchilik shu zahoti DISTINCT qo'shadi va davom etadi.

SELECT DISTINCT c.name, o.amount
FROM customers c
JOIN orders o ON o.customer_id = c.id;

Muammo: DISTINCT sababni emas, alomatni yashiradi. Dublikat paydo bo'lgan bo'lsa, demak JOIN kaliti o'ng jadvalda unikal emas. Va agar ikki mijozning summasi tasodifan teng bo'lsa — DISTINCT ulardan birini o'chirib tashlaydi. Hisobot jimgina noto'g'ri bo'ladi.

Avval dublikat borligini tekshiring:

SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Dublikat qatorlarni o'chirish (eng ishonchli usul — ROW_NUMBER):

WITH d AS (
    SELECT id,
           ROW_NUMBER() OVER (PARTITION BY email
                              ORDER BY created_at) AS rn
    FROM users
)
DELETE FROM users
WHERE id IN (SELECT id FROM d WHERE rn > 1);

Bu har bir email uchun eng eskisini qoldiradi, qolganini o'chiradi.

⚠️ DELETE yozishdan oldin doim shu so'rovni SELECT bilan bir marta ishga tushiring — nima o'chishini ko'ring.

📌 DISTINCT yozgingiz kelsa, avval bitta savol bering: bu dublikat qayerdan keldi?

🎯 Endi amaliyot: Takrorlangan email larni topish
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Ertalabki test javobi: 4-o'rin

RANK() tenglardan keyin o'rinni sakratadi: 1, 2, 2, 4. Uchinchi o'rin umuman bo'lmaydi.
DENSE_RANK() esa sakratmaydi: 1, 2, 2, 3.

Amalda bu qayerda muhim?

Vazifa: «top 3 mahsulot» ro'yxatini chiqaring.

-- DENSE_RANK: teng natijalar ham kiradi
WHERE drnk <= 3   -- 3 ta o'rin, lekin 4-5 qator bo'lishi mumkin

-- ROW_NUMBER: qat'iy 3 qator
WHERE rn <= 3

Agar boshliq «menga aniq 3 qator kerak» desa — ROW_NUMBER. Agar «uchinchi o'rinni bo'lishganlar ham chiqsin» desa — DENSE_RANK.

Bu texnik emas, biznes savoli. Shuning uchun analitik so'rov yozishdan oldin aniqlab oladi.

💬 Sizning ishingizda «top N» qanday hisoblanadi?

🎯 Endi amaliyot: Takroriy yozuvlarni tozalash
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki masala: ketma-ket kunlar

Jadval: logins(user_id, login_date) — har bir kirish bitta qator.

Vazifa: kamida 3 kun ketma-ket tizimga kirgan foydalanuvchilarni toping.

Masalan:
• user 1 → 5, 6, 7-oktabr ✅
• user 2 → 5, 6, 8-oktabr ❌

SELECT user_id
FROM logins
???

⚠️ Ogohlantirish: bu masala GROUP BY bilan yechilmaydi. Bu yerda boshqa usul kerak.

🎯 Bu «gaps and islands» deb ataladigan klassik masala. Uni bilgan odam intervyuda darrov ajralib turadi.

✍️ Fikringizni izohda yozing, 13:00 da to'liq tahlil qilamiz 👇

🎯 Endi amaliyot: 3+ ketma-ket kun kirgan foydalanuvchilar
Masala saytda tayyor turibdi — urinib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🏝 Gaps and islands: ketma-ketlikni qanday topish kerak

Ertalabki masalaning yechimi. Butun sir bitta hiylada.

Hiyla: agar sanalar ketma-ket bo'lsa, ularning tartib raqami ham ketma-ket o'sadi. Demak sana − tartib_raqami ayirmasi bitta «orolcha» ichida o'zgarmaydi.

WITH t AS (
    SELECT user_id, login_date,
           login_date - (ROW_NUMBER() OVER (
               PARTITION BY user_id
               ORDER BY login_date
           ) * INTERVAL '1 day') AS grp
    FROM (SELECT DISTINCT user_id, login_date FROM logins) x
)
SELECT user_id
FROM t
GROUP BY user_id, grp
HAVING COUNT(*) >= 3;

Nima bo'lyapti?
5, 6, 7-oktabr → raqamlari 1, 2, 3 → ayirma har uchalasida bir xil → bitta guruh, 3 qator → shart bajarildi.
5, 6, 8-oktabr → 8 da ayirma o'zgaradi → yangi guruh boshlanadi → hech qaysi guruhda 3 ta yo'q.

⚠️ SELECT DISTINCT shart: bitta kunda ikki marta kirgan bo'lsa, raqamlar siljib ketadi va natija buziladi.

📌 Xuddi shu usul boshqa joylarda ham ishlaydi:
• streak hisoblash (ketma-ket kunlar)
• uzluksiz ishlagan davrlar
• sensor ma'lumotlaridagi uzilishlar
• abonement to'lovlaridagi bo'shliqlar

💬 Bu usulni bilarmidingiz? Boshqa yechim taklif qila olasizmi?

🎯 Endi amaliyot: Eng uzun g'alabalar seriyasi
Xuddi shu usul bilan yechiladi — mustahkamlab oling 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🎯 SQL ni o'qib emas, yozib o'rganasiz

Bugungi «gaps and islands» masalasini o'qib chiqdingiz. Tushundingiz. Endi rostini aytaylik: bir haftadan keyin uni o'zingiz noldan yoza olasizmi?

Ko'pchilik yoza olmaydi. Chunki o'qish — tanish tuyg'usi beradi, ko'nikma bermaydi. Ko'nikma faqat bo'sh oynaga so'rov yozib, xato olib, tuzatib paydo bo'ladi.

Shuning uchun sqlmaster.uz qurildi:

🔹 195 ta masala — SELECT asoslaridan window funksiya va CTE gacha
🔹 Real schemalar — Uzum, Click, taksi, bank jadvallari. O'quv misollari emas, ishdagi vaziyatlar
🔹 Yozasiz — tizim darrov tekshiradi. To'g'ri javobni emas, sizning so'rovingiz natijasini solishtiradi
🔹 Muhokama bo'limi — boshqalarning yechimini ko'rasiz. Bitta masalaning 5 xil yechimi bo'ladi
🔹 Bosqichma-bosqich — Oson → O'rtacha → Qiyin

💡 Birinchi 50 ta masala mutlaqo bepul. Ro'yxatdan o'tish 30 soniya, karta kerak emas.

Bugun 3 ta masala yeching. Ertaga yana 3 ta. Bir oydan keyin intervyuda «JOIN yozib bering» degan gap sizni cho'chitmaydi.

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

☕ Ertalabki savol: qaysi biri tezroq?

Ikkala so'rov ham bir xil natija beradi — buyurtma bergan mijozlar ro'yxati.

-- 1-variant
SELECT * FROM customers c
WHERE c.id IN (SELECT customer_id FROM orders);

-- 2-variant
SELECT * FROM customers c
WHERE EXISTS (
    SELECT 1 FROM orders o
    WHERE o.customer_id = c.id
);

Sizningcha qaysi biri tezroq ishlaydi?

A) IN tezroq
B) EXISTS tezroq
C) Farqi yo'q

✍️ Javobingizni izohda yozing. Kechqurun 20:00 da query plan bilan ko'rsataman 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

🐌 Index bor, lekin so'rov sekin. Nega?

Index yaratilgan bo'lsa ham, baza uni ishlatmasligi mumkin. Mana eng ko'p uchraydigan 5 holat:

1️⃣ Ustunga funksiya qo'llansa

WHERE DATE(created_at) = '2026-10-06'   -- index ishlamaydi
WHERE created_at >= '2026-10-06'
  AND created_at <  '2026-10-07'        -- index ishlaydi

Index created_at qiymatlarini saqlaydi, DATE(created_at) natijasini emas.

2️⃣ LIKE boshida foiz bo'lsa
LIKE 'Ali%' — ishlaydi
LIKE '%Ali' — ishlamaydi (index alifbo tartibida, boshi noma'lum)

3️⃣ Tip mos kelmasa
WHERE phone = 998901234567 — phone matn ustuni bo'lsa, baza har qatorni songa aylantiradi va index chetda qoladi. Tirnoq qo'ying.

4️⃣ OR ishlatilsa
WHERE a = 1 OR b = 2 — ko'pincha to'liq skan. UNION ALL bilan ikki so'rovga bo'lish tezroq bo'lishi mumkin.

5️⃣ Jadval kichik bo'lsa
1000 qatorli jadvalda to'liq o'qish indexdan tez. Bu xato emas — optimizator to'g'ri qaror qilyapti.

📌 Taxmin qilmang, tekshiring:

EXPLAIN ANALYZE
SELECT ...;

Natijada Seq Scan ko'rsangiz — index ishlamayapti. Index Scan yoki Bitmap Index Scan ko'rsangiz — ishlayapti.

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz

✅ Javob: C — zamonaviy bazalarda farqi deyarli yo'q

PostgreSQL va SQL Server optimizatori IN va EXISTS ni ko'pincha bir xil planga aylantiradi (semi-join). Ya'ni «EXISTS doim tezroq» degan eski maslahat bugun har doim ham to'g'ri emas.

Lekin ikkita muhim farq bor 👇

1️⃣ NULL bilan xulq-atvor. NOT IN ichida bitta NULL bo'lsa, natija butunlay bo'sh chiqadi. NOT EXISTS da bunday muammo yo'q. Shuning uchun inkorda doim NOT EXISTS.

2️⃣ Ichki ro'yxat katta bo'lsa. IN (1, 2, 3, ... 10000) ko'rinishidagi qo'lda yozilgan uzun ro'yxat sekin ishlaydi — vaqtinchalik jadval yoki JOIN afzal.

Uchinchi variant — JOIN:

SELECT DISTINCT c.*
FROM customers c
JOIN orders o ON o.customer_id = c.id;

⚠️ Bu yerda DISTINCT kerak bo'ldi, chunki mijozning 5 ta buyurtmasi bo'lsa 5 marta chiqadi. EXISTS da bu muammo yo'q — u «bormi?» degan savolga javob beradi, ko'paytirmaydi.

📌 Xulosa: «bor-yo'qligini» tekshirish uchun — EXISTS. Ustun kerak bo'lsa — JOIN.

💬 EXPLAIN ANALYZE ni ishlatib ko'rganmisiz?

🎯 Endi amaliyot: EXISTS va IN — qayta yozish
O'qib tushundingiz — endi o'zingiz yozib ko'ring 👇

➖➖➖➖➖➖➖➖
💾 Amaliyot: sqlmaster.uz
📢 @sqlmasteruz