MariaDB / المتوسط: التزامن وSQL القابلة لإعادة الاستخدام / الدرس 8

الفهارس وقراءة EXPLAIN

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

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

في هذه الصفحة

أهداف الدرس

ربط ترتيب الفهرس المركب بالشروط والفرز.
تمييز الخطة التقديرية عن تحليل التنفيذ.

الفهرس مسار وصول بديل

يرتب فهرس B-tree المفاتيح ليجد المحرك جزءاً مفيداً دون فحص كل الصفوف. ليس مفتاح سرعة عاماً؛ فقد يكون المسح أرخص لجدول صغير أو شرط يطابق معظم الصفوف. ينظم InnoDB البيانات حول المفتاح الأساسي وتحمل الفهارس الثانوية معلوماته، لذلك يضخم المفتاح العريض البنى الثانوية أيضاً. يستهلك كل فهرس مساحة ويزيد عمل الإضافة والتحديث والحذف.

طابق بحث الشحنات

لبحث الشحنات الحديثة لعميل معين، ضع customer_id أولاً لأنه مقيد بالمساواة، ثم created_at للمجال وshipment_id لكسر التعادل. هذا تصميم مرشح لا ضمان لخطة محددة؛ يؤثر الحجم والتوزيع والأعمدة المطلوبة والفهارس الحالية. لا يستخدم التعريف إلا في عينة مختبر مراجعة. تقدّر EXPLAIN الوصول قبل التنفيذ، ولا يمكن استنتاج الصفوف والكلفة الفعلية من أسماء الأعمدة.

sql SQL توضيحي؛ النتائج المتوقعة مستنتجة وليست قياسات.

CREATE INDEX ix_ship_customer_time
ON shipments (customer_id, created_at, shipment_id);
EXPLAIN SELECT shipment_id, created_at FROM shipments
WHERE customer_id = 7 AND created_at >= '2026-10-01'
ORDER BY created_at, shipment_id LIMIT 20;

افحص المفتاح المختار وتقدير الصفوف. تعتمد خلايا الخطة على العينة وإصدار الخادم.

فسر عدة إشارات للخطة معاً

تسمي possible_keys المرشحين وkey الفهرس المختار في EXPLAIN التقليدية. يصف type طريقة الوصول: ALL مسح جدول، بينما ref وrange شكلان للوصول المفهرس. rows تقدير لا عدد مقاس. تصف Using filesort عملية فرز ولا تثبت وحدها كتابة إلى القرص. قد تعني Using index تغطية الفهرس لا بحثاً انتقائياً. احكم على الاستعلام والحمل كاملين.

أبقِ العمود المفهرس قابلاً للبحث

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

sql SQL توضيحي؛ النتائج المتوقعة مستنتجة وليست قياسات.

EXPLAIN SELECT shipment_id FROM shipments
WHERE DATE(created_at) = '2026-10-01';
EXPLAIN SELECT shipment_id FROM shipments
WHERE created_at >= '2026-10-01'
  AND created_at < '2026-10-02';

لا ندعي نسبة سرعة؛ تكشف الصيغة الثانية مجالاً صريحاً، وتحويلات المحسن تعتمد على الإصدار.

تحليل التنفيذ ينفذ فعلاً

تنفذ MariaDB ANALYZE SELECT وANALYZE FORMAT=JSON SELECT الاستعلام وتضيف معلومات مرصودة مثل إحصاءات الصفوف الفعلية. تختلفان عن ANALYZE TABLE التي تحدث إحصاءات المحسن. لا تفترض تطابق صيغة MySQL EXPLAIN ANALYZE أو مخرجاتها. ابدأ بـ EXPLAIN واستعلام قراءة ممثل داخل المختبر. قِس توزيع الزمن والصفوف المفحوصة وكلفة الكتابة؛ لا تثبت تجربة مخبأة سريعة واحدة فائدة الإنتاج.

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

يوجد فهرس لكن الاستعلام يمسح الجدول

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

تُعرض rows كعدد مقاس

لماذا يحدث؟: اختلط تقدير EXPLAIN بقياس التنفيذ.
كيف تصلحه؟: سم التقديرات واجمع مشاهدات ANALYZE المضبوطة منفصلة.
كيف تتجنب تكراره؟: سجل العبارة التي أنتجت كل تشخيص.

تتباطأ الكتابة بعد إضافة فهارس كثيرة

لماذا يحدث؟: يصون كل تغيير بنى الفهارس الإضافية.
كيف تصلحه؟: راجع الفهارس الزائدة مقابل الحمل الكامل قبل حذف منضبط.
كيف تتجنب تكراره؟: ضمّن إنتاجية الكتابة والتخزين في معايير قبول الفهرس.

اختبر فهمك

1. هل يبدأ فهرس (customer_id, created_at) بحثاً فعالاً باستخدام created_at وحده دائماً؟

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

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

2. تذكر الخطة Using filesort لنتيجة عشرين صفاً. هل تزيلها فوراً؟