تحسين أداء قاعدة البيانات: 10 خطوات فعّالة

لماذا تحسين قاعدة البيانات مهم؟

قاعدة البيانات هي عنق الزجاجة الأكثر شيوعا في أي تطبيق ويب. استعلام واحد بطيء يؤثر على كل مستخدم يمر بنفس المسار. تحسين أداء القاعدة لا يعني فقط سرعة أكبر، بل يعني تقليل تكلفة السيرفر لأن نفس العتاد يخدم عدد أكبر من الطلبات.

الفرق بين قاعدة بيانات محسنة وغير محسنة قد يصل لـ 100 ضعف في زمن الاستجابة. استعلام يستغرق 5 ثوان يمكن تحسينه ليعمل في 50 مللي ثانية بالتقنيات الصحيحة.

الفهارس (Indexes): أهم أداة تحسين

كيف تعمل الفهارس؟

بدون فهرس، القاعدة تفحص كل صف في الجدول للعثور على البيانات المطلوبة (Full Table Scan). مع فهرس، القاعدة تقفز مباشرة للصفوف المطلوبة عبر بنية شجرية (B-Tree).

مثال عملي: جدول فيه مليون صف. بدون فهرس يفحص المليون صف. مع فهرس يفحص 20 صف فقط.

أنواع الفهارس

النوع	الاستخدام	المثال
B-Tree	الافتراضي، مقارنات ونطاقات	WHERE status = 'active'
Hash	مقارنات المساواة فقط	WHERE id = 123
GIN	البحث النصي وJSON	WHERE data @> '{"key": "value"}'
GiST	البيانات الجغرافية	ST_Contains(geom, point)
Composite	عدة أعمدة معا	WHERE status = 'active' AND created_at > '2026-01-01'

قواعد إنشاء الفهارس

1. فهرس على كل عمود في WHERE: إذا تبحث بعمود بشكل متكرر، أنشئ فهرس عليه
2. فهارس مركبة بترتيب صحيح: العمود الأكثر تصفية أولا
3. لا تبالغ: كل فهرس يبطئ عمليات الكتابة. أضف فقط ما تحتاجه فعلا
4. فهرس على Foreign Keys: ضروري لتسريع JOINs

كشف الفهارس الناقصة

-- MySQL: الاستعلامات البطيئة
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- PostgreSQL: تحليل الاستعلام
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 1234;

ابحث عن "Seq Scan" في PostgreSQL أو "Full Table Scan" في MySQL. هذه علامات على فهارس ناقصة.

تحسين الاستعلامات

استخدم EXPLAIN

قبل تحسين أي استعلام، افهم كيف تنفذه القاعدة:

EXPLAIN ANALYZE
SELECT o.id, c.name, SUM(o.total)
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.created_at > '2026-01-01'
GROUP BY o.id, c.name;

تجنب SELECT *

حدد الأعمدة التي تحتاجها فقط. SELECT * يقرأ كل الأعمدة حتى لو تحتاج واحد فقط:

-- سيء
SELECT * FROM users WHERE id = 1;

-- جيد
SELECT name, email FROM users WHERE id = 1;

تجنب N+1 Problem

أحد أكثر مشاكل الأداء شيوعا في تطبيقات الويب:

-- سيء: N+1 (101 استعلام لـ 100 طلب)
SELECT * FROM orders;
-- ثم لكل طلب:
SELECT * FROM customers WHERE id = ?;

-- جيد: استعلام واحد
SELECT o.*, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id;

استخدم الفهرسة التغطوية (Covering Index)

-- إذا هذا استعلام متكرر:
SELECT name, email FROM users WHERE status = 'active';

-- أنشئ فهرس يغطي كل الأعمدة:
CREATE INDEX idx_users_status_covering
ON users (status) INCLUDE (name, email);

ضبط إعدادات القاعدة

MySQL (InnoDB)

# /etc/mysql/mysql.conf.d/mysqld.cnf

# Buffer Pool: 70-80% من RAM المتاح
innodb_buffer_pool_size = 6G

# حجم ملف السجل
innodb_log_file_size = 1G

# عدد خيوط الإدخال/الإخراج
innodb_read_io_threads = 8
innodb_write_io_threads = 8

# التنظيف التلقائي
innodb_purge_threads = 4

# ذاكرة مؤقتة للاستعلامات
tmp_table_size = 256M
max_heap_table_size = 256M

PostgreSQL

# /etc/postgresql/16/main/postgresql.conf

# ذاكرة مشتركة: 25% من RAM
shared_buffers = 2GB

# ذاكرة العمل لكل استعلام
work_mem = 64MB

# ذاكرة الصيانة
maintenance_work_mem = 512MB

# فعالية ذاكرة التخزين المؤقت
effective_cache_size = 6GB

# الاتصالات المتزامنة
max_connections = 200

# WAL
wal_buffers = 64MB
checkpoint_completion_target = 0.9

تحسين الجداول

التقسيم (Partitioning)

الجداول الكبيرة (ملايين الصفوف) تستفيد من التقسيم:

-- PostgreSQL: تقسيم بالتاريخ
CREATE TABLE orders (
 id SERIAL,
 created_at TIMESTAMP,
 total DECIMAL
) PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025 PARTITION OF orders
 FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

CREATE TABLE orders_2026 PARTITION OF orders
 FOR VALUES FROM ('2026-01-01') TO ('2027-01-01');

تنظيف البيانات القديمة

البيانات التي لا تحتاجها تبطئ كل شيء:

• الأرشفة: انقل البيانات القديمة لجداول أرشيف
• الحذف المجدول: احذف السجلات المنتهية بشكل دوري
• TTL: حدد عمر افتراضي للبيانات المؤقتة

المراقبة المستمرة

مقاييس يجب مراقبتها

المقياس	القيمة الطبيعية	تنبيه عند
زمن الاستعلام المتوسط	أقل من 100ms	أكثر من 500ms
الاتصالات النشطة	أقل من 80% من الحد	أكثر من 90%
Cache Hit Ratio	أكثر من 95%	أقل من 90%
القفل المتبادل (Deadlocks)	0	أي عدد
استخدام التخزين	أقل من 70%	أكثر من 80%

أدوات المراقبة

• pg_stat_statements: لتتبع أبطأ الاستعلامات في PostgreSQL
• Performance Schema: لتتبع الأداء في MySQL
• pgBadger: تحليل سجلات PostgreSQL
• Percona Monitoring: مراقبة شاملة لـ MySQL

الخلاصة

تحسين قاعدة البيانات عملية مستمرة وليست مهمة لمرة واحدة. ابدأ بالفهارس ثم حسن الاستعلامات ثم اضبط الإعدادات. راقب الأداء باستمرار واستجب للتغيرات. على سيرفرات كلاود (cloud.net.sa) تحصل على تخزين SSD سريع يقلل زمن الإدخال والإخراج بشكل كبير، مع إمكانية ترقية الذاكرة والمعالج فوريا عندما يحتاج تطبيقك موارد أكبر.

---

ابدأ الآن

تبي تجرب بنفسك؟ اختر باقة الاستضافة المناسبة أو صمم سيرفرك الخاص بالمواصفات اللي تبيها.