MySQL / التطبيقات الموثوقة والاستعلامات التحليلية / الدرس 8

القيود والفهارس الموجهة

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

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-23

في هذه الصفحة

أهداف الدرس

اشرح سلوك CHECK و UNIQUE و NOT NULL والمفاتيح الخارجية.
صمم فهارس مركبة دون ضمان ترتيب النتائج أواستخدام الفهرس.

قواعد القاعدة تحمي جميع الكتّاب

استخدم بيانات المتجر وافحص قيودها قبل التغيير. تشترط NOT NULL وجود قيمة وتتحقق CHECK من تعبير وتمنع UNIQUE تكرار المفتاح ويشترط المفتاح الخارجي مرجعاً مطابقاً للقيم غير NULL. تسري الضمانات بين التطبيقات والجلسات المتزامنة. وتكمل فحص التطبيق الذي يشرح الإدخال غير الصحيح قبل وصوله إلى القاعدة.

افهم NULL داخل القيود

تقبل CHECK في MySQL النتيجة الصحيحة أوالمجهولة وترفض الخاطئة. لذلك تسمح CHECK (stock >= 0) وحدها بـ NULL؛ وضمها إلى NOT NULL يعبر عن قاعدة المخزون. وقد يحمل مفتاح UNIQUE القابل للغياب قيماً NULL متعددة، فلا يساوي معرّفاً مطلوباً فريداً. ويفحص InnoDB المفاتيح الخارجية فوراً ولا يؤجل التحقق إلى التثبيت.

sql افحص القواعد ومسارات الوصول

SHOW CREATE TABLE order_items;
SHOW INDEX FROM orders;

تكشف SHOW CREATE TABLE المفتاح المركب والقيود والمراجع، وتحدد SHOW INDEX الفهارس ومنها الداعمة للعلاقات. قد تختلف الأسماء والتنسيقات، لذا لا نعرض مخرجات خادم كاملة مختلقة. اقرأ التعريف الفعلي قبل اقتراح فهرس مكرر أوافتراض حذف متسلسل.

تبادل الفهارس التخزين مقابل الوصول

يخزن InnoDB بيانات الصف في بنية المفتاح الأساسي العنقودية. وتتضمن سجلات الفهرس الثانوي قيمة المفتاح الأساسي، فيزيد اتساعه تكلفة الفهارس الثانوية. ويصون كل إدراج أوحذف أوتحديث ذي صلة الفهارس المتأثرة. لذلك قد تبطئ فهرسة كل عمود الكتابة وتستهلك الذاكرة. اختر الفهارس للاستعلامات المتكررة المكلفة.

رتّب الأعمدة حسب متطلبات الاستعلام

يدعم فهرس مركب على customer_id و placed_at و id المساواة على العميل ثم نطاق الوقت. تهم بادئاته اليسرى خصوصاً، فلا يضمن شرط placed_at وحده وصولاً مماثلاً. وتتوقف التغطية على جميع أعمدة الاختيار والتصفية، ومنها المفتاح الأساسي المخزن في الفهرس الثانوي. وقد يختار المحسن المسح إذا كان أرخص.

sql فهرس مركب يناسب الاستعلام

CREATE INDEX ix_orders_customer_time ON orders(customer_id,placed_at,id);
SELECT id,placed_at FROM orders
WHERE customer_id=1 AND placed_at>='2026-01-01'
ORDER BY placed_at,id;

الناتج المتوقع

id | placed_at
101 | 2026-01-10 10:00:00
102 | 2026-01-11 11:00:00

لا يغير أمر DDL الاختياري المنفذ مرة واحدة صفوف التدريب. يعيد SELECT الطلب 101 ثم 102. الفهرس مسار مرشح وليس دليلاً على اختياره. وتبقى ORDER BY لازمة حتى لو وفر الفهرس الترتيب المطلوب. سنفحص EXPLAIN بدلاً من استنتاج الخطة من الاسم.

تحقق من المعنى قبل السرعة

يجب توافق أنواع أعمدة المرجع، بما فيها حجم الأعداد وإشارتها، وتحتاج النصوص إلى إعدادات محارف متوافقة. أشر إلى مفتاح أساسي أوفريد بدلاً من الاعتماد على سلوك InnoDB قديم غير معياري. حدد المخالفات وسياسة إصلاحها قبل إضافة قيد للبيانات الموجودة. إضافة الفهرس أوالقيد DDL لها آثار أقفال وتثبيت مستقلة عن صحة الاستعلام.

الأخطاء الشائعة وإصلاحها

تمر NULL عبر CHECK ظننتها تشترط القيمة.

لماذا يحدث؟: يعطي التعبير نتيجة مجهولة تقبلها CHECK.
كيف تصلحه؟: أضف NOT NULL إن كان الغياب غير صالح ونظف القيم المفقودة أولاً.
كيف تتجنب تكراره؟: افحص حالات الصحيح والخاطئ والمجهول لكل قاعدة.

ERROR 3780 (HY000) عند إنشاء مفتاح خارجي.

لماذا يحدث؟: تختلف تعريفات الأعمدة المرجعية، مثل العدد الموقع وغير الموقع.
كيف تصلحه؟: وحّد التعريفات بعد تدقيق مدَيَي القيم.
كيف تتجنب تكراره؟: صمم نوع المفتاح مرة وأعد استخدام تعريفه نفسه.

ERROR 1061 (42000): Duplicate key name.

لماذا يحدث؟: أُعيد نص CREATE INDEX الاختياري باسم الفهرس نفسه.
كيف تصلحه؟: افحص SHOW INDEX وتجاوز التغيير المطبق بالفعل.
كيف تتجنب تكراره؟: تتبع تغييرات المخطط بترحيلات مرقمة منفصلة عن تدريب الاستعلام.

اختبر فهمك

1. هل يضمن فهرس (customer_id, placed_at) كفاءة شرط placed_at وحده؟

اعرض الحل المشروح

لا؛ إذ يغيب مكوّن العميل الأول فلا تعزل البادئة اليسرى المعتادة النطاق الزمني مباشرة. افحص الخطة وعبء العمل قبل إضافة فهرس يبدأ بالوقت؛ فكل فهرس إضافي يكلف صيانة.

2. اشرح حاجة المخزون إلى CHECK و NOT NULL معاً.