هل عرض الخلية دائما لا تفحص الجدول الكامل؟

Question

وأنا أحاول لتحسين استعلام الذي يستخدم طريقة عرض في الخلية 5.1. ويبدو أنه حتى إذا قمت بتحديد العمود 1 من مشاهدته دائما لا تفحص الجدول الكامل. غير أن السلوك المتوقع؟

والرأي مجرد SELECT. "جميع أعمدة من هذه الجداول - لا *" للجداول لقد المحددة في الاستعلام الأول أدناه

وهذا هو بلدي شرح الإخراج من عندما حدد فهرسة العمود PromotionID من الاستعلام التي تشكل الرأي. كما ترون كان مختلفا إلى حد كبير من الإخراج على طريقة العرض.

EXPLAIN SELECT pb.PromotionID FROM PromotionBase pb INNER JOIN PromotionCart pct ON pb.PromotionID = pct.PromotionID INNER JOIN PromotionCode pc ON pb.PromotionID = pc.PromotionID WHERE pc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pc
         type: const
possible_keys: PRIMARY,fk_pc_pb
          key: PRIMARY
      key_len: 302
          ref: const
         rows: 1
        Extra:
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: pb
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using index
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: pct
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
        Extra: Using index
3 rows in set (0.00 sec)

وإخراج عندما حدد نفس الشيء ولكن من وجهة نظر

EXPLAIN SELECT vpc.PromotionID FROM vw_PromotionCode vpc  WHERE vpc.PromotionCode = '5TAFF312C0NT'\G;
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 5830
        Extra: Using where
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: pcart
         type: index
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 33
        Extra: Using index
*************************** 3. row ***************************
           id: 2
  select_type: DERIVED
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pcart.PromotionID
         rows: 1
        Extra:
*************************** 4. row ***************************
           id: 2
  select_type: DERIVED
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 5. row ***************************
           id: 3
  select_type: UNION
        table: pp
         type: index
possible_keys: PRIMARY
          key: pp_p
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 6. row ***************************
           id: 3
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pp.PromotionID
         rows: 1
        Extra:
*************************** 7. row ***************************
           id: 3
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 8. row ***************************
           id: 4
  select_type: UNION
        table: pcp
         type: index
possible_keys: PRIMARY
          key: pcp_cp
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 9. row ***************************
           id: 4
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.pcp.PromotionID
         rows: 1
        Extra:
*************************** 10. row ***************************
           id: 4
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 11. row ***************************
           id: 5
  select_type: UNION
        table: ppc
         type: index
possible_keys: PRIMARY
          key: ppc_pc
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 12. row ***************************
           id: 5
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.ppc.PromotionID
         rows: 1
        Extra:
*************************** 13. row ***************************
           id: 5
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 14. row ***************************
           id: 6
  select_type: UNION
        table: ppt
         type: index
possible_keys: PRIMARY
          key: ppt_pt
      key_len: 4
          ref: NULL
         rows: 1
        Extra: Using index
*************************** 15. row ***************************
           id: 6
  select_type: UNION
        table: pb
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: readyinteractive.ppt.PromotionID
         rows: 1
        Extra:
*************************** 16. row ***************************
           id: 6
  select_type: UNION
        table: pc
         type: ref
possible_keys: fk_pc_pb
          key: fk_pc_pb
      key_len: 4
          ref: readyinteractive.pb.PromotionID
         rows: 249
        Extra: Using where
*************************** 17. row ***************************
           id: NULL
  select_type: UNION RESULT
        table: <union2,3,4,5,6>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: NULL
        Extra:
17 rows in set (0.18 sec)

Answer 1

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

تعديل: وبطبيعة الحال سوف تستخدم الفهارس على الجداول الأساسية بحيث عرض نفسه هو الأمثل (وإلا فإنها لن تقدم أي معنى على الإطلاق لاستخدام) ولكن لأنه لا توجد مؤشرات المشاهدات على مشاهدة فإنه ليس من الممكن لWHERE الاستعلام عن عرض ليكون الأمثل.

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

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

وإذا كان كل ويتضمن هذا الرأي هو SELECT ALL من TABLE1، table2، table3. ثم أود أن أسأل لماذا يحتاج هذا الاستعلام لتكون في طريقة عرض على الإطلاق؟ إذا كان لسبب وجودها ضروري للغاية، قد ترغب في استخدام إجراء مخزن لتغليف الاستعلام كما عليك أن تكون ثم قادرا على الحصول على الأداء الأمثل مع الحفاظ على مصلحة مكالمة أبسط لقاعدة البيانات لمجموعة النتائج.

Answer 2

ولقد ألقيت نظرة أعمق إلى أنه ولقد غاب عن نقطة أساسية من المعلومات :( وجهة نظري الاستعلام لديها في الواقع اتحاد مع جدول آخر، وهذا يسبب بغية استخدام خوارزمية جدول مؤقت بدلا من الخوارزمية الدمج.

والخوارزمية جدول مؤقت لا تسمح باستخدام الفهارس في الجداول الأساسية.

ويبدو أن هذا خطأ في الخلية وأفيد في طريق العودة في عام 2006 لكنه لا يبدو أنه قد تم حلها في عام 2009! http://forums.mysql.com/read.php؟100،56681، 56681

ويبدو أنا فقط ستكون لدينا لإعادة كتابة الاستعلام صلة خارجية.