SQLite / المتوسط: بنية الاستعلام وتصميم المعاملة / الدرس 10
خطط الاستعلام والإحصاءات والأدلة المقاسة
فسّر EXPLAIN QUERY PLAN في SQLite دون اعتبار نصه واجهة ثابتة، وميّز مسار الوصول المفيد من ادعاء أداء لا يسنده قياس.
في هذه الصفحة
أهداف الدرس
- اقرأ SEARCH وSCAN والفرز المؤقت في سياق الاستعلام.
- افصل وصف الخطة عن قياس التنفيذ الفعلي.
- راجع الإحصاءات وافتراضات إصدار المحرك.
اسأل عن العمل الذي تنفذه الاستراتيجية المختارة
يصف EXPLAIN QUERY PLAN استراتيجية وصول عالية المستوى: الوصول للجداول والفهارس، وتعشيق الوصلات، وبعض البنى المؤقتة. وليس ملف قياس تنفيذ فعلي بأزمنة أو أعداد صفوف موحدة الدلالة. يعرض EXPLAIN الكامل تعليمات الآلة الافتراضية كتمثيل تشخيصي أدنى مستوى. تحقق من الدعم قبل نقل افتراضات EXPLAIN ANALYZE من محرك آخر إلى SQLite.
تحذر الوثائق الرسمية من تغير تنسيق EQP عبر الإصدارات. رُصدت الصفوف هنا على 3.45.1؛ هي أدلة تعلم لا بروتوكول تطبيق دائم التحليل. ليست معرّفات العقد وصياغة الوصف بيانات أعمال. تعرضها أداة لشخص، بينما يعتمد المنتج نتائج الاستعلام والواجهات الموثقة.
اقرأ بحثاً انتقائياً بالمفتاح الأساسي
يبحث النص الأول عن قيمة INTEGER PRIMARY KEY واحدة. تصف الخطة المختبرة البحث بهوية rowid، ثم يعيد SELECT القيمة alpha مؤكداً صحة النتيجة. تصف الخطة المسار لا الزمن؛ فقد يكلف SEARCH كثيراً لاتساع نطاقه أو كثرة عملياته اللاحقة، فلا يمثل اسمه ساعة قياس.
افحص الشرط وعدد الصفوف المتوقع والأعمدة المطلوبة وبقية الفرز والتصفية. قد يجنب الفهرس المغطي الرجوع للجدول، لكن كثرة أعمدته تزيد كلفة الكتابة والحجم. وفي الوصلات المتعشقة حدد المصدر المستخدم لكل صف خارجي؛ فقد تهيمن عمليات بحث صغيرة متكررة على الحمل ولو بدت كل عملية مفهرسة.
CREATE TABLE note(id INTEGER PRIMARY KEY,body TEXT);
INSERT INTO note VALUES(1,'alpha'),(2,'beta');
EXPLAIN QUERY PLAN SELECT body FROM note WHERE id=1;
SELECT body FROM note WHERE id=1;
id|parent|notused|detail
2|0|0|SEARCH note USING INTEGER PRIMARY KEY (rowid=?)
body
alpha
تبحث الخطة المرصودة بالمفتاح الأساسي الصحيح، وتكون النتيجة alpha. أما الصياغة الدقيقة لمخرجات EQP فتعتمد على الإصدار.
لاحظ متى يحتاج الترتيب عملاً مؤقتاً
يطلب النص الثاني أولاً ترتيب body بلا فهرس مطابق. تمسح خطة 3.45.1 المرصودة الجدول وتستخدم شجرة B مؤقتة للترتيب. وبعد إنشاء فهرس body يمكنها مسح البنية المغطية. ويبقى SELECT الأخير مصرحاً بترتيبه؛ فلا يلغي الفهرس عقد ترتيب المخرجات.
هذه مقارنة بنيوية على صفين لا تسريع إنتاجي مقاس. وليس الفرز المؤقت عيباً بذاته؛ فقد يلائم نتيجة صغيرة أو تقريراً نادراً. قيّم الذاكرة والإدخال والإخراج وحجم النتيجة وكلفة الكتابة معاً. واسأل هل يستفيد الحمل الكامل دون تغيير النتائج أو فرض كلفة غير مقبولة لتعديل البيانات.
CREATE TABLE note(id INTEGER PRIMARY KEY,body TEXT);
INSERT INTO note VALUES(1,'alpha'),(2,'beta');
EXPLAIN QUERY PLAN SELECT id,body FROM note ORDER BY body,id;
CREATE INDEX note_body ON note(body);
EXPLAIN QUERY PLAN SELECT id,body FROM note ORDER BY body,id;
SELECT id,body FROM note ORDER BY body,id;
id|parent|notused|detail
3|0|0|SCAN note
10|0|0|USE TEMP B-TREE FOR ORDER BY
id|parent|notused|detail
3|0|0|SCAN note USING COVERING INDEX note_body
id|body
1|alpha
2|beta
يستبدل المحرك المختبر الفرز المؤقت باجتياز الفهرس المغطي. وتبقى النتيجة الصفين نفسيهما بالترتيب المصرح به.
عامل الإحصاءات والمعاملات كسياق للخطة
يستخدم المخطط معلومات البنية والقيود والفهارس والإحصاءات المتاحة. تجمع ANALYZE إحصاءات التخطيط، بينما يعتمد PRAGMA optimize وسلوك الصيانة الموصى به على الإصدار. اقرأ وثائق النسخة المنشورة؛ فلا تصف كل توصية حالية بيئة التحقق 3.45.1. وصيانة الإحصاءات نفسها عمل يحتاج مالكاً وغرضاً.
قارن فئات معاملات وتوزيعات ممثلة. قد تلائم خطة عميلاً نادراً ولا تلائم قيمة شائعة، ولا يمثل جدول تدريبي صغير متجانس هذا الانحراف. وقد يعتمد سلوك إعادة إعداد العبارة والتخطيط على الواجهة وصيغة العبارة. احفظ SQL الفعلي وأنواع القيم المرتبطة والمخطط والمحرك مع كل ادعاء تحسن.
قس عملاً قابلاً للمقارنة دون إعادة ضبط أنظمة مشتركة
نفذ القياس على بيانات اصطناعية معزولة أو بيانات ممثلة معتمدة فقط، بنتائج متطابقة وظروف مضبوطة. سجل الحالة الدافئة أو الباردة، وعدد الاستعلامات والصفوف المعادة، وكلفة البيئة المضيفة وحدود الموارد. توفر واجهات الحالة في C وتشخيصات الصدفة عدادات مفيدة، لكن عرض نص SQL برد تتبع في Python ليس ملف قياس تنفيذ. وقد يحوي التشخيص قيماً حساسة تحتاج ضبط وصول.
أجر تغييراً واحداً مسنداً بالدليل، وتحقق من الاستعلام والكتابات المتأثرة. تجنب وصفات كفرض كل فهرس، أو VACUUM بعد كل تغيير، أو إفراغ مخبأ مشترك للاختبار. تشرح ملاحظة الضبط الفرضية والاستراتيجية المرصودة والأثر المقاس وصحة النتائج وحدود الاستنتاج، ومنها الاعتماد على إصدار SQLite محدد.
الأخطاء الشائعة وإصلاحها
تعطل محلل نصي بعد ترقية SQLite.
- لماذا يحدث؟
- عومل نص EQP التشخيصي كواجهة تطبيق ثابتة.
- كيف تصلحه؟
- اعتمد عقود النتائج والواجهات الموثقة، واحتفظ بنص الخطة للتشخيص الواعي بالإصدار.
- كيف تتجنب تكراره؟
- اربط كل خطة مرصودة بإصدار المحرك الذي أنتجها.
افتُرض أن كل SEARCH أسرع من كل SCAN.
- لماذا يحدث؟
- حلت أسماء العمليات محل قياس حمل العمل.
- كيف تصلحه؟
- افحص العمل المطلوب للصفوف المطابقة وقس الاستعلام كاملاً.
- كيف تتجنب تكراره؟
- قارن النتائج وعدد الصفوف وكلفة الموارد.
استُخدم قياس صغير لتبرير تغيير فهرس على نطاق عام.
- لماذا يحدث؟
- أخفت البيانات غير الممثلة أثر التوزيع وكلفة الكتابة.
- كيف تصلحه؟
- اختبر فئات ممثلة وعمليات التعديل المتأثرة في بيئة معزولة.
- كيف تتجنب تكراره؟
- سجل حمل العمل ومعايير الرجوع عن التغيير.
اختبر فهمك
1. ماذا يخبرك استخدام شجرة B مؤقتة لتنفيذ ORDER BY، وماذا لا يثبته؟
اعرض الحل المشروح
يدل على أن الاستراتيجية المختارة تحتاج عملاً مؤقتاً لترتيب هذا الاستعلام. لكنه لا يثبت بطء الاستعلام، أو إمكان تجنب الفرز في جميع الظروف، أو استفادة الحمل الكامل من فهرس إضافي. قس حجم النتائج وتكرار التنفيذ ومفاضلات تعديل البيانات قبل التصرف.
2. لماذا تحفظ إصدار SQLite الفعلي مع مثال EQP محفوظ؟
اعرض الحل المشروح
قد يتغير تنسيق التشخيص وقرارات المخطط. فالملاحظة المحفوظة دليل لبيئة محددة، وليست بروتوكول نصوص صالحاً لكل زمن. قارن النتائج الدلالية مستقلاً، وأعد تقييم التحسين عند تغير المخطط البنيوي أو البيانات أو المحرك.
أهم ما تعلمته
- تصف الخطة استراتيجية، لا نتيجة زمنية عامة.
- مخرجات EQP مادة تشخيصية حساسة للإصدار.
- تكمل الإحصاءات وتوزيعات البيانات وكلفة الكتابة سياق ضبط الأداء.