این داستان ‏Query Planning 😯

احتمالا با دیتابیس هایی مثل PostgreSQL یا MySQL کوئری زدین، اگه دقت کرده باشید این کوری ها چه ساده باشن چه پیچیده سریع اجرا میشن، دلیلشم تو یه فرایند جالب به اسم Query Planning هست.
تو این پست قراره ببینیم چیه، چطور کار می‌کنه.

‏🧠 Query Planning چیه؟

‏Query Planning (یا برنامه‌ریزی کوئری) فرایندی تو دیتابیس‌های رابطه‌ایه که توش دیتابیس تصمیم می‌گیره بهترین راه برای اجرای یه کوئری SQL چیه. وقتی یه کوئری مثل SELECT * FROM users WHERE age > 30
می‌نویسین، دیتابیس نمی‌ره مستقیم اجرا کنه؛ اول یه نقشه می‌کشه که چطور داده‌ها رو پیدا کنه، فیلتر کنه و برگردونه. این نقشه که بهش Query Plan یا Execution Plan می‌گن، مثل یه GPSه که به دیتابیس می‌گه از کدوم مسیر بره تا سریع‌تر به مقصد برسه.

هدف اصلیش بهینه‌سازی پرفورمنس با کم کردن زمان اجرا، مصرف CPU، حافظه و I/O (خوندن/نوشتن دیسک). دیتابیس این کار رو با تحلیل ساختار کوئری، آمار جدول‌ها و ایندکس‌ها انجام می‌ده.

‏📚 Query Planning چطور کار می‌کنه؟

دیتابیس‌ها (مثل PostgreSQL، MySQL، SQL Server) یه بخش به اسم Query Optimizer دارن که مسئول ساختن پلن بهینه‌ست. بیاین قدم‌به‌قدم ببینیم چی به چیه:

1⃣ پارس کردن کوئری (Parsing)
دیتابیس اول کوئری رو بررسی می‌کنه تا مطمئن شه درست نوشته شده (از نظر گرامری و معنایی). مثلاً چک می‌کنه جدول users وجود داره یا نه.
خروجی این مرحله یه درخت نحوی (parse tree)ه که ساختار کوئری رو نشون می‌ده.

2⃣ بازنویسی کوئری (Rewriting)
تو این مرحله، دیتابیس کوئری رو ساده‌تر یا بهینه‌تر می‌کنه، بدون اینکه نتیجه‌ش تغییر کنه. مثلاً:
  تبدیل ساب کوری ها به جوین‌ها.
  حذف شرط‌های اضافی (مثل WHERE TRUE).
تو PostgreSQL، این کار توسط Query Rewriter انجام می‌شه.

3⃣ تولید پلن‌های ممکن (Plan Generation)
حالا Query Optimizer کلی پلن ممکن برای اجرای کوئری می‌سازه. مثلاً برای یه کوئری ساده:

  SELECT * FROM users WHERE age > 30;
  

  ممکنه این گزینه‌ها بررسی شه:

  ‏Sequential Scan:
کل جدول رو خط‌به‌خط بخونه.

  ‏Index Scan:
از ایندکس روی ستون age استفاده کنه.

  ‏Bitmap Scan:
ترکیبی از ایندکس و اسکن.

برای کوئری‌های پیچیده (با جوین، گروه‌بندی و غیره)، تعداد پلن‌ها می‌تونه به هزارتا برسه

4️⃣ تخمین هزینه (Cost Estimation)
دیتابیس برای هر پلن یه هزینه (cost) تخمین می‌زنه. این هزینه یه عدد خیالیه که شامل:

  مصرف CPU (برای مقایسه‌ها، مرتب‌سازی و غیره).

  ‏I/O (خوندن از دیسک یا کش).

شبکه (اگه دیتابیس توزیع‌شده باشه).

دیتابیس از آمار جدول‌ها (مثل تعداد ردیف‌ها، توزیع داده‌ها) و ساختار ایندکس‌ها برای این تخمین استفاده می‌کنه.
مثلاً تو PostgreSQL، دستور ANALYZE این آمار رو به‌روز می‌کنه.

5️⃣ انتخاب بهترین پلن
‏Optimizer پلنی رو انتخاب می‌کنه که کمترین هزینه رو داره. این پلن می‌شه Execution Plan و برای اجرا به Executor فرستاده می‌شه.
تو بعضی دیتابیس‌ها (مثل Oracle)، می‌تونین از hints استفاده کنین تا Optimizer رو به یه پلن خاص هدایت کنین.

6️⃣ اجرا و بازخورد
بعد از اجرا، دیتابیس ممکنه بازخورد بگیره (مثلاً آمار واقعی تعداد ردیف‌ها) و پلن‌های بعدی رو بهتر کنه.

🛠 چرا Query Planning مهمه؟

‏Query Planning مثل مغز دیتابیسه و مستقیم روی پرفورمنس تأثیر می‌ذاره:

سرعت: یه پلن خوب می‌تونه یه کوئری رو از چند دقیقه به چند میلی‌ثانیه برسونه.

مصرف منابع: پلن بد می‌تونه CPU و دیسک رو بیخودی درگیر کنه و سرور رو خفه کنه.

مقیاس‌پذیری: تو دیتابیس‌های بزرگ با میلیون‌ها ردیف، یه پلن بهینه فرق بین موفقیت و فاجعه‌ست.

تجربه کاربر: اگه API‌تون به یه دیتابیس کند وصل باشه، کاربراتون فرار می‌کنن

🔍 مشکلات رایج تو Query Planning

آمار قدیمی: اگه آمار جدول‌ها به‌روز نباشه، Optimizer ممکنه پلن بد انتخاب کنه.

کوئری‌های پیچیده: جوین‌های چندگانه یا شرط‌های مبهم می‌تونن Optimizer رو گیج کنن.

عدم ایندکس: بدون ایندکس، دیتابیس مجبوره کل جدول رو اسکن کنه.

دیتابیس‌های توزیع‌شده:
تو دیتابیس‌هایی مثل CockroachDB، شبکه هم به معادله اضافه می‌شه و پلن‌ها پیچیده‌تر می‌شن.

✍ جمع‌بندی

‏Query Planning مثل یه شطرنج‌باز حرفه‌ایه که تو دیتابیس تصمیم می‌گیره بهترین حرکت چیه. با تحلیل کوئری، آمار جدول‌ها و ایندکس‌ها، یه پلن بهینه می‌سازه که می‌تونه سرعت و کارایی پروژه‌تون رو زیر و رو کنه.

#️⃣ #web #programming #db

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP