هذا الدليل جزء من مجموعة من الدروس المستفادة من لقاءات المجتمع. ولمزيد من الحلول والرؤى العملية، يمكنك التصفح حسب مشكلة محددة.
هل تؤدي مشكلة Too Many Parts إلى إبطاء قاعدة بياناتك؟ اطّلع على دليل رؤى المجتمع Too Many Parts.
تعرّف على المزيد حول Materialized Views.
النمط المضاد لتضخيم التخزين بمقدار 10x
مشكلة حقيقية في بيئة الإنتاج: “كان لدينا عرض مادي. كان حجم جدول السجلات الخام نحو 20 غيغابايت، لكن العرض المادي المبني على جدول السجلات هذا تضخّم إلى 190 غيغابايت، أي ما يقارب 10 أضعاف حجم الجدول الخام. حدث ذلك لأننا كنا ننشئ صفًا لكل سمة، ويمكن أن يحتوي كل سجل على 10 سمات.”
القاعدة: إذا كان GROUP BY ينشئ صفوفًا أكثر مما يُلغي، فأنت تبني فهرسًا مكلفًا، لا عرضًا ماديًا.
التحقق من سلامة العرض المادي في بيئة الإنتاج
يساعدك هذا الاستعلام على توقّع ما إذا كان العرض المادي سيضغط بياناتك أو سيتسبب في تضخّمها قبل إنشائه. شغّله على الجدول والأعمدة الفعلية لديك لتجنّب سيناريو “التضخّم إلى 190GB”.
ما الذي يوضحه:
- نسبة تجميع منخفضة (<10%) = عرض مادي جيد مع ضغط كبير
- نسبة تجميع مرتفعة (>70%) = عرض مادي سيئ مع خطر تضخّم التخزين
- مضاعِف التخزين = مقدار كِبر/صِغر حجم العرض المادي لديك
عندما تصبح العروض المادية مشكلة
علامات التحذير التي ينبغي مراقبتها:
- يزداد زمن استجابة الإدراج (فالاستعلامات التي كانت تستغرق 10ms أصبحت الآن تستغرق 100ms+)
- ظهور أخطاء “Too many parts” بوتيرة أكبر
- ارتفاع مفاجئ في CPU أثناء عمليات الإدراج
- حدوث حالات انتهاء مهلة للإدراج لم تكن تظهر من قبل
يمكنك مقارنة أداء الإدراج قبل إضافة MVs وبعدها باستخدام system.query_log لتتبّع اتجاهات مدة الاستعلامات.
آخر تعديل في ٣ يوليو ٢٠٢٦