كيف تحسّن أداء استعلامات SQL البطيئة؟

Question

Accepted Answer

يبدأ تحسين الاستعلامات البطيئة بـ **تحليل خطة التنفيذ** (`EXPLAIN`) للعثور على نقطة الاختناق، ثم تطبيق إصلاحات موجهة — غالباً **إضافة فهارس**، إعادة كتابة الاستعلام، وتجنب الأنماط الشائعة السيئة. أكبر ربح عادة ما يكون تحويل عمليات المسح الكامل للجدول إلى عمليات بحث سريعة باستخدام الفهارس.

## الخطوة 1: التحليل باستخدام EXPLAIN

```sql
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 5;
-- shows the EXECUTION PLAN: scan type (Seq Scan = full scan, Index Scan = using an index),
-- estimated/actual rows, cost, and timing → reveals WHERE the time goes
```

`EXPLAIN` (أو `EXPLAIN ANALYZE`) يُظهر كيف تنفذ قاعدة البيانات الاستعلام — بشكل حاسم، ما إذا كانت تقوم بـ **مسح كامل للجدول** (بطيء) أو استخدام **فهرس** (سريع). احرص دائماً على قياس الأداء قبل التحسين.

## أكبر ربح: إضافة فهارس

```sql
-- if EXPLAIN shows a Seq Scan on a filtered/joined column → add an index
CREATE INDEX idx_orders_customer ON orders(customer_id);
-- turns a full scan into a fast index lookup
```

الإصلاح الأكثر شيوعاً وتأثيراً: **إضافة فهارس** على الأعمدة المستخدمة في `WHERE`, `JOIN`, و `ORDER BY`. هذا يحول المسح الكامل للجدول إلى عمليات بحث سريعة.

## الأنماط السيئة الشائعة التي يجب إصلاحها

```sql
-- ❌ functions on a column prevent index use
WHERE UPPER(email) = 'X@Y.COM'        -- can't use an index on email
WHERE email = 'x@y.com'               -- ✅ can use the index

-- ❌ leading wildcard LIKE can't use an index
WHERE name LIKE '%smith'              -- ✅ 'smith%' (prefix) can use an index

-- ❌ SELECT * fetches unneeded columns
SELECT * → SELECT only_needed_columns  -- less data, may use a covering index

-- ❌ N+1 queries (querying in a loop) → use a single JOIN instead
```

## تقنيات التحسين الأخرى

```text
✓ Fix N+1 queries (one query per row) → use JOINs / batch into one query
✓ Add appropriate indexes (including COMPOSITE for multi-column filters)
✓ Reduce data scanned — filter early, select only needed columns, paginate
✓ Rewrite subqueries as JOINs where more efficient
✓ Use EXISTS instead of IN for existence checks on large subqueries
✓ Keep statistics updated (ANALYZE) so the planner makes good choices
✓ Consider denormalization / materialized views for expensive repeated queries
✓ Watch for missing indexes on FOREIGN KEYS (joins scan without them)
```

## لماذا يهمّ الأمر

تحسين الاستعلامات معرفة حاسمة لأداء قاعدة البيانات — الاستعلامات البطيئة هي أحد الأسباب الرئيسية لضعف أداء التطبيقات، والقدرة على إيجادها وإصلاحها مهارة أساسية على مستوى رفيع لأي شخص يعمل مع قواعد البيانات على نطاق واسع.

الانضباط الأساسي هو **التحليل باستخدام `EXPLAIN`** (فحص خطة التنفيذ للعثور على نقطة الاختناق الفعلية — بشكل حاسم ما إذا كان الاستعلام يقوم بمسح كامل بطيء أو بحث سريع باستخدام الفهرس) قبل التحسين، بدلاً من التخمين — هذا النهج القائم على القياس هو ما يجعل التحسين فعالاً.

**أكبر وأكثر ربح شيوعاً هو إضافة فهارس** على الأعمدة المُرشحة والمُدمجة والمرتبة (تحويل عمليات المسح الكامل للجدول إلى عمليات بحث سريعة — غالباً ما يحسّن وقت الاستعلام بأضعاف)، مما يجعل معرفة الفهارس محورية للتحسين.

فهم **الأنماط السيئة الشائعة** مهم بنفس القدر: الدوال على الأعمدة و`LIKE` بأحرف بدل في البداية تمنع استخدام الفهارس، `SELECT *` يجلب بيانات غير ضرورية، والأهم من ذلك **استعلامات N+1** (الاستعلام في حلقة بدلاً من `JOIN` واحد — وهي قاتل أداء متكرر وخطير في كود التطبيق) — التعرف عليها وإصلاحها يعالج أكثر الأسباب شيوعاً للاستعلامات البطيئة.

تقنيات أخرى (الفهارس المركبة، تقليل البيانات الممسوحة، إعادة كتابة الاستعلامات الفرعية كـ JOINات، إبقاء الإحصائيات محدثة، الآراء المادية للاستعلامات المكلفة) تكمل مجموعة الأدوات.

نظراً لأن أداء الاستعلام تؤثر بشكل مباشر على استجابة وقابلية توسع التطبيق، وبما أن النهج المنهجي (التحليل باستخدام EXPLAIN، ثم الإصلاح — عادة بإضافة فهارس والقضاء على الأنماط السيئة مثل N+1) هو ما يحافظ على سرعة قواعد البيانات تحت الحمل، فإن إتقان تحسين الاستعلامات مهارة رفيعة المستوى مهمة وعالية القيمة تميز المطورين الذين يمكنهم بناء تطبيقات موثوقة وقابلة للتوسع مدعومة بقواعد بيانات — مهارة حرجة وذات صلة متكررة وموضوع شائع في المقابلات المتعلقة بأداء قواعد البيانات.