آموزش بیش از ۵۰۰ سوال مصاحبه MySQL به همراه پاسخ‌ها ۲۰۲۶ - آخرین آپدیت

پوشش تفصیلی حوزه‌های آزمون

این مخزن آزمون‌های تمرینی دقیقاً به گونه‌ای ساختار یافته است که بازتاب‌دهنده توزیع فنی سوالات در مصاحبه‌های واقعی MySQL و مهندسی دیتابیس در سطح سازمان‌های بزرگ باشد.

• مدل‌سازی داده و طراحی دیتابیس (۱۵٪): مدل‌سازی موجودیت-رابطه (ER)، نرمال‌سازی دیتابیس (از 1NF تا BCNF)، دنورمالیزاسیون هدفمند، مفاهیم انبار داده، شمای Star و Snowflake، و طراحی جداول Fact و Dimension.

• زبان کوئری MySQL و ایندکس‌گذاری (۲۰٪): دستورات پیشرفته SELECT، Joinهای پیچیده، Subqueryهای چند سطحی، استراتژی‌های ایندکس‌گذاری (B-Tree, Hash, Composite)، تحلیل عمیق طرح اجرا با EXPLAIN و ANALYZE، تکنیک‌های بهینه‌سازی کوئری و جستجوی Full-Text.

• دستکاری داده‌ها و مدیریت تراکنش‌ها (۱۸٪): اجرای ایمن دستورات INSERT، UPDATE و DELETE، مدیریت تراکنش‌های ACID، مکانیزم‌های قفل‌گذاری (Shared, Exclusive, Intent)، جریان‌های Rollback و Commit، Savepointها، Cursorها و ارزیابی دقیق سطوح جداسازی تراکنش (Read Uncommitted, Read Committed, Repeatable Read, Serializable).

• امنیت داده‌ها و کنترل دسترسی (۱۲٪): مدیریت حساب‌های کاربری، سیستم امتیازدهی (Privilege) در MySQL، جلوگیری از SQL Injection، توابع رمزگذاری و رمزگشایی ساختاری، پارامترهای امنیت در سطح ردیف (Row-Level Security) و مرزهای امنیتی Viewها و Stored Procedureها.

• تنظیم عملکرد و بهینه‌سازی MySQL (۱۸٪): پارامترهای پیکربندی دیتابیس (my.cnf / my.ini)، پروفایلینگ کوئری‌ها، مانیتورینگ Performance Schema و Sys Schema، تنظیم ایندکس‌ها، مکانیزم‌های کشینگ، مدیریت InnoDB Buffer Pool و تفاوت‌های ساختاری عمیق بین موتورهای InnoDB و MyISAM.

• پشتیبان‌گیری، بازیابی و نگهداری دیتابیس (۱۰٪): استخراج‌های منطقی از طریق mysqldump و mysqlpump، بازیابی نقطه زمانی با استفاده از Binary Logها، مدیریت لاگ‌های تکثیر، استراتژی‌های Backup و Recovery، بررسی InnoDB File-Per-Table در مقابل Shared Tablespaces و ابزارهای نگهداری مانند mysqlcheck و mysql_upgrade.

• در دسترس بودن بالا (HA) و مقیاس‌پذیری MySQL (۷٪): معماری‌های تکثیر (Asynchronous, Semi-synchronous, Master-Slave / Source-Replica)، کلاستر Galera، توپولوژی‌های Group Replication، شاردینگ (Sharding)، پارتیشن‌بندی افقی، Load Balancing با HAProxy، MySQL Router و ادغام ProxySQL.

درباره این دوره

قبولی در مصاحبه فنی برای نقش‌های سطح بالای توسعه‌دهنده MySQL، مهندس داده یا مدیر دیتابیس (DBA)، بسیار فراتر از دانستن نحوه نوشتن یک کوئری ساده SELECT است. اپلیکیشن‌های سازمانی مدرن نیازمند نرخ تراکنش بالا، یکپارچگی تراکنشی آهنین و لایه‌های داده بهینه‌ای هستند که زیر بارهای سنگین تولید متوقف نشوند. مصاحبه‌کنندگان اغلب در جزئیات موتور ذخیره‌سازی، اثرات جانبی جداسازی تراکنش‌ها، طرح‌های اجرا و توپولوژی‌های کلاسترینگ جستجو می‌کنند تا مطمئن شوند می‌توانید داده‌ها را با مسئولیت مدیریت کنید. من این بانک سوالات جامع را طراحی کردم تا شکاف بین آشنایی ساده با سینتکس و سناریوهای پیچیده‌ای که پنل‌های مصاحبه ارشد برای تست متقاضیان استفاده می‌کنند را پر کنم.

با ۵۵۰ سوال تمرینی بسیار دقیق و اورجینال، این دوره بسیار فراتر از تعاریف سطحی می‌رود. من چالش‌های ایندکس‌گذاری در سطح محیط عملیاتی، موانع تنظیم کوئری، Deadlockها، شکست‌های پشتیبان‌گیری و تحلیل‌های مربوط به معماری High Availability را کالبدشکافی کرده‌ام. هر سوال با یک تحلیل گام‌به‌گام و جامع همراه است که توضیح می‌دهد چرا راهکار بهینه موفق می‌شود و چرا گزینه‌های جایگزین تحت فشار واقعی شکست می‌خورند. چه به دنبال جایگاه مدیریت دیتابیس باشید، چه برای مراحل طراحی مهندسی داده بک‌اند آماده شوید یا بخواهید دانش بهینه‌سازی کوئری خود را پیش از یک ارزیابی فنی بزرگ تقویت کنید، این منبع تمرینات سخت‌گیرانه‌ای را فراهم می‌کند که برای قبولی با اعتماد به نفس در اولین تلاش به آن‌ها نیاز دارید.

نمونه‌ای از سوالات تمرینی

برای درک عمق و سبک ساختاری توضیحات فنی ارائه شده در این بانک سوالات، این سه نمونه سوال با کیفیت بالا را بررسی کنید.

سوال ۱: انتخاب ایندکس و رفتار کلید ترکیبی (Compound Key) در کوئری‌های با حجم بالا

یک توسعه‌دهنده یک ایندکس ترکیبی روی یک جدول پرترافیک با تعریف زیر ایجاد می‌کند: CREATE INDEX idx_user_status_date ON users (status, created_at, country_code);. یک کوئری گزارش با دستور زیر اجرا می‌شود: SELECT user_id FROM users WHERE created_at > '2026-01-01' AND country_code = 'IN';. هنگام بررسی اجرا از طریق دستور EXPLAIN، بهینه‌ساز (Optimizer) به جای استفاده از ایندکس ترکیبی، یک Full Table Scan را نشان می‌دهد. دلیل ساختاری این رفتار چیست؟

• الف) کوئری از یک اپراتور محدوده (بزرگتر از) استفاده می‌کند که ایندکس‌های ترکیبی را در تمام ستون‌ها به طور کامل غیرفعال می‌کند.

• ب) کوئری با حذف ستون پیشرو status از عبارت‌های فیلتر، قانون Leftmost Prefix را نقض می‌کند.

• ج) ابزار EXPLAIN نمی‌تواند ارزیابی ایندکس ترکیبی را ردیابی کند اگر کلید اصلی user_id در لیست select باشد.

• د) ایندکس‌های ترکیبی در MySQL محدود به تطبیق‌های دقیق (Equality) هستند و نمی‌توانند انواع داده‌های تاریخ را به صورت بومی ارزیابی کنند.

• ه) ترتیب ستون‌ها در اعلان ایندکس باید دقیقاً با توالی ستون‌ها در شمای فیزیکی دیتابیس مطابقت داشته باشد.

• و) ایندکس به طور خودکار باطل می‌شود زیرا فیلتر country_code در انتهای رشته کوئری قرار دارد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا صحیح است: ایندکس‌های ترکیبی B-Tree در MySQL دقیقاً از قانون Leftmost Prefix پیروی می‌کنند. برای اینکه بهینه‌ساز کوئری بتواند از ایندکس idx_user_status_date استفاده کند، عبارت‌های کوئری باید شامل اولین ستون تعریف شده در ایندکس، یعنی status باشند. از آنجایی که کوئری فقط روی created_at و country_code فیلتر می‌کند، بهینه‌ساز نمی‌تواند به طور موثر از ریشه درخت ایندکس پیمایش کند و بنابراین کاملاً از آن صرف‌نظر کرده و به Full Table Scan باز می‌گردد.

• چرا گزینه‌های جایگزین نادرست هستند:

  • گزینه الف نادرست است: اپراتورهای محدوده ایندکس‌های ترکیبی را به طور کامل غیرفعال نمی‌کنند؛ آن‌ها فقط مانع از استفاده بهینه‌ساز از ستون‌های بعدی ایندکس برای فیلتر کردن می‌شوند.

  • گزینه ج نادرست است: گنجاندن user_id در لیست select در واقع در سناریوی Covering Index به نفع ایندکس است؛ EXPLAIN این مورد را به راحتی ردیابی می‌کند.

  • گزینه د نادرست است: ایندکس‌های ترکیبی با استفاده از مکانیسم‌های استاندارد مرتب‌سازی B-Tree، تاریخ‌ها را به خوبی مدیریت می‌کنند.

  • گزینه ه نادرست است: توالی ستون‌ها در تعریف جدول دیتابیس هیچ تاثیری بر نحوه رفتار ایندکس ترکیبی ندارد.

  • گزینه و نادرست است: موقعیت فیزیکی یک عبارت در متن رشته کوئری اهمیتی ندارد؛ بهینه‌ساز پیش از ارزیابی، عبارت‌ها را به صورت داخلی بازآرایی می‌کند.

سوال ۲: ارزیابی Deadlockها در سطح جداسازی Repeatable Read

دو تراکنش همزمان دستوراتی را روی یک جدول InnoDB که دارای ایندکس روی employee_id است اجرا می‌کنند. سطح جداسازی تراکنش روی مقدار پیش‌فرض REPEATABLE READ تنظیم شده است. تراکنش ۱ دستور SELECT * FROM employees WHERE employee_id = 45 FOR UPDATE; را اجرا می‌کند. به طور همزمان، تراکنش ۲ دستور SELECT * FROM employees WHERE employee_id = 50 FOR UPDATE; را اجرا می‌کند. هر دو ردیف وجود دارند. بلافاصله پس از آن، تراکنش ۱ سعی می‌کند رکورد جدیدی با employee_id = 48 درج کند، در حالی که تراکنش ۲ سعی می‌کند رکوردی با employee_id = 49 درج کند. دیتابیس خطای Deadlock می‌دهد. مکانیسم بنیادی ایجاد کننده این خطا چیست؟

• الف) قفل‌های Exclusive ردیفی روی رکوردهای موجود هنگام استفاده از FOR UPDATE به طور خودکار کل فضای جدول را قفل می‌کنند.

• ب) سطح جداسازی REPEATABLE READ تمام قفل‌های Exclusive سطح ردیف را به قفل‌های متادیتای مشترک (Shared) تبدیل می‌کند.

• ج) هر دو تراکنش برای دسترسی به Gap Lockهای هم‌پوشان در محدوده ایندکس بین ID 45 و ID 50 رقابت می‌کنند.

• د) دستورات Insert زمانی که هر تراکنش همزمان از یک حلقه Cursor فعال استفاده کند، به طور کامل از اجرا منع می‌شوند.

• ه) موتور ذخیره‌سازی هر زمان که دو ID تراکنش متمایز نوشتن‌های همزمان را اجرا کنند، یک Rollback خودکار را فعال می‌کند.

• و) ساختار ایندکس فاسد شده است زیرا کلیدهای اصلی در لایه ذخیره‌سازی فیزیکی بیش از حد به هم نزدیک هستند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• چرا صحیح است: در سطح جداسازی REPEATABLE READ، موتور InnoDB از Next-Key Locking برای جلوگیری از Phantom Readها استفاده می‌کند. یک Next-key lock ترکیبی از یک Record Lock روی رکورد ایندکس و یک Gap Lock روی فاصله قبل از رکورد ایندکس است. وقتی هر دو تراکنش کوئری‌های FOR UPDATE را روی رکوردهای مجاور یا نزدیک اجرا می‌کنند، Gap Lockهای مربوط به آن‌ها می‌تواند در فضای ایندکس بین مقادیر ۴۵ و ۵۰ هم‌پوشانی داشته باشد. وقتی هر دو سپس سعی می‌کنند داخل آن فاصله مشترک درج کنند، منتظر آزاد شدن Gap Lockهای یکدیگر می‌مانند که منجر به یک حلقه Deadlock کلاسیک می‌شود.

• چرا گزینه‌های جایگزین نادرست هستند:

  • گزینه الف نادرست است: InnoDB ردیف‌های تکی و فواصل خاص ایندکس را قفل می‌کند؛ مگر اینکه از ستونی بدون ایندکس در فیلتر استفاده شود، در غیر این صورت به قفل کامل جدول ارتقا نمی‌یابد.

  • گزینه ب نادرست است: درخواست‌های FOR UPDATE قفل‌های Exclusive می‌خواهند، نه قفل‌های Shared؛ سطوح جداسازی درخواست‌های صریح قفل‌گذاری را تغییر نمی‌دهند.

  • گزینه د نادرست است: درج‌های همزمان در سطح جهانی مجاز هستند، تا زمانی که هدف آن‌ها یک Gap قفل شده نباشد یا باعث نقض کلید اصلی تکراری نشوند.

  • گزینه ه نادرست است: Rollbackها تنها در صورتی فعال می‌شوند که یک وضعیت Deadlock واقعی توسط آشکارساز Deadlock در پس‌زمینه موتور شناسایی شود، نه صرفاً به دلیل اجرای همزمان.

  • گزینه و نادرست است: نزدیکی مقادیر عددی کلیدهای اصلی هیچ تاثیری بر فساد دیتابیس یا پایداری لایه فیزیکی ندارد.

سوال ۳: تنظیم دقیق InnoDB Buffer Pool برای کاهش گلوگاه‌های I/O دیسک

یک مدیر دیتابیس (DBA) در محیط عملیاتی متوجه گلوگاه‌های شدید Read I/O دیسک در ساعات اوج پردازش می‌شود. پس از بررسی وضعیت موتور، DBA تایید می‌کند که نرخ Hit در Buffer Pool پایین است، به این معنی که صفحات به طور مداوم اخراج شده و دوباره از ذخیره‌ساز دیسک خوانده می‌شوند. کدام استراتژی تنظیم پارامتر پیکربندی مستقیماً این گلوگاه عملکردی خاص را کاهش می‌دهد؟

• الف) کاهش اندازه innodb_log_buffer_size برای اجبار به مراحل سریع‌تر لاگ‌گذاری تراکنش‌ها.

• ب) افزایش innodb_buffer_pool_size برای اجازه دادن به داده‌ها و صفحات ایندکس بیشتر جهت استقرار در حافظه.

• ج) تغییر max_connections به آستانه بالاتر برای پردازش همزمان رشته‌های (Threads) بیشتر.

• د) تغییر innodb_flush_log_at_trx_commit از مقدار ۱ به ۰ برای بهینه‌سازی دوام تراکنش‌ها.

• ه) تغییر تنظیم query_cache_type برای فعال‌سازی کامل کشینگ کوئری‌ها در تمام شماهای رابطه‌ای.

• و) کاهش اندازه فایل‌های Tablespace تکی برای تسریع موقعیت‌دهی هد خواندن در درایو فیزیکی دیسک.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• چرا صحیح است: پارامتر innodb_buffer_pool_size حیاتی‌ترین پارامتر برای عملکرد MySQL هنگام استفاده از موتور InnoDB است. این پارامتر تعیین می‌کند چه مقدار حافظه برای کش کردن داده‌های جدول و ایندکس‌ها اختصاص یابد. با افزایش این مقدار (معمولاً تا ۷۰-۸۰٪ از کل RAM سیستم در سرورهای اختصاصی دیتابیس)، صفحات داده بیشتری در حافظه می‌مانند، که به طور قابل توجهی دفعات خواندن از دیسک را کاهش داده و نسبت Cache Hit را افزایش می‌دهد.

• چرا گزینه‌های جایگزین نادرست هستند:

  • گزینه الف نادرست است: کاهش اندازه بافر لاگ، کشینگ لاگ‌های تراکنش را محدود کرده و باعث افزایش سربار نوشتن روی دیسک می‌شود که I/O را بدتر می‌کند.

  • گزینه ج نادرست است: افزایش حداکثر اتصالات اجازه می‌دهد رشته‌های کاربر همزمان بیشتری فعال شوند، اما هیچ تاثیری روی کش کردن صفحات داده یا کاهش فشار حافظه ندارد.

  • گزینه د نادرست است: تغییر innodb_flush_log_at_trx_commit ایمنی Flush لاگ‌های تراکنش به دیسک را تغییر می‌دهد (کاهش ریسک‌های I/O نوشتن)، اما به کشینگ صفحات داده یا کاهش Missهای Read I/O کمک نمی‌کند.

  • گزینه ه نادرست است: مکانیزم Query Cache به دلیل گلوگاه‌های مقیاس‌پذیری در MySQL 8.0 به طور کامل منسوخ و حذف شده است، بنابراین این تنظیم بی‌ارتباط است.

  • گزینه و نادرست است: تقسیم یا کاهش اندازه تخصیص جداول، مکانیسم‌های کشینگ منطقی را در ساختارهای حافظه تغییر نمی‌دهد.

انتظارات از دوره

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را برای ارزیابی سوالات مصاحبه MySQL آماده کنیم.

• شما می‌توانید هر تعداد بار که بخواهید در آزمون‌ها شرکت کنید.

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• با اپلیکیشن Udemy سازگار با موبایل است.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.