क्या MySQL दृश्य हमेशा पूर्ण टेबल स्कैन करता है?

मैं एक क्वेरी को अनुकूलित करने की कोशिश कर रहा हूं जो MySQL 5.1 में एक दृश्य का उपयोग करता है। ऐसा लगता है कि अगर मैं दृश्य से 1 कॉलम का चयन करता हूं तो यह हमेशा एक पूर्ण टेबल स्कैन करता है। क्या यह अपेक्षित व्यवहार है?क्या MySQL दृश्य हमेशा पूर्ण टेबल स्कैन करता है?

दृश्य केवल उन तालिकाओं के लिए "इन तालिकाओं से सभी कॉलम - नहीं *" चुनें, जिन्हें मैंने नीचे दी गई पहली क्वेरी में निर्दिष्ट किया है।

यह मेरी व्याख्या है जब मैं इंडेक्स किए गए कॉलम प्रोमोशन आईडी को क्वेरी से चुनता हूं जो दृश्य बनाता है। जैसा कि आप देख सकते हैं कि यह दृश्य के आउटपुट से काफी अलग है।

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)

उत्पादन जब मैं एक ही बात का चयन लेकिन दृश्य MySQL में

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)

स्रोत

2009-03-12 Alex

दृश्य उनके स्वभाव से तो अनुक्रमित नहीं कर रहे हैं से एक पूर्ण स्कैन प्रत्येक बार पहुँचे जाने की आवश्यकता है। आम तौर पर यह दृश्यों को वास्तव में केवल उन परिस्थितियों के लिए उपयोगी बनाता है जहां आपके पास एक जटिल जटिल क्वेरी है जो एक छोटा परिणाम सेट देता है और आप हर बार पूरे परिणाम सेट को पकड़ने की योजना बनाते हैं।

संपादित करें: बेशक दृश्य अंतर्निहित मेज पर अनुक्रमित का उपयोग करेगा ताकि खुद को देखें अनुकूलित है (अन्यथा वे सब पर उपयोग करने के लिए कोई मतलब नहीं होता है), लेकिन क्योंकि वहाँ एक यह दृश्य पर कोई अनुक्रमणिका हैं दृश्य को अनुकूलित करने के लिए WHERE क्वेरी के लिए संभव नहीं है।

दृश्यों के लिए इंडेक्स तैयार करना वैसे भी महंगा होगा क्योंकि मैंने किसी भी दृश्य को देखने की कोशिश नहीं की है, लेकिन मैं निश्चित रूप से निश्चित हूं कि दृश्यों के पीछे एक अस्थायी तालिका बनाई गई है और फिर परिणाम सेट वापस आ गया है। अस्थायी तालिका बनाने में पहले से ही काफी समय लगता है, मैं एक ऐसा दृश्य नहीं देखना चाहूंगा जो यह अनुमान लगाने का प्रयास करे कि इंडेक्स की क्या ज़रूरत है। जो दूसरा बिंदु लाता है जो कि MySQL वर्तमान में यह निर्दिष्ट करने के लिए एक विधि प्रदान नहीं करता है कि एक दृश्य के लिए कौन से इंडेक्स का उपयोग करना है, तो यह कैसे पता चलेगा कि किन क्षेत्रों को अनुक्रमित करने की आवश्यकता है? क्या यह आपकी क्वेरी के आधार पर अनुमान लगाता है?

आप Temporary Table का उपयोग करने पर विचार कर सकते हैं क्योंकि तब आप अस्थायी तालिका में फ़ील्ड पर अनुक्रमणिका निर्दिष्ट कर सकते हैं। हालांकि, अनुभव से यह वास्तव में वास्तव में धीमा हो जाता है।

यदि यह सब दृश्य तालिका 1, तालिका 2, तालिका 3 से सभी का चयन है; तो मुझे यह पूछना होगा कि इस प्रश्न को एक दृश्य में क्यों होना चाहिए? अगर किसी कारण से यह बिल्कुल जरूरी है, तो आप क्वेरी को समाहित करने के लिए संग्रहीत प्रक्रिया का उपयोग करना चाहेंगे क्योंकि परिणाम परिणाम के लिए डेटाबेस को एक सरल कॉल के लाभ को बनाए रखते हुए आप अनुकूलित प्रदर्शन प्राप्त कर पाएंगे।

स्रोत

2009-03-12 04:27:19

यह यहां http://dev.mysql.com/doc/refman/5.0/en/view-restrictions.html कहता है कि दृश्य अंतर्निहित तालिकाओं की अनुक्रमणिका का उपयोग करेगा। – Alex

मुझे पूरा यकीन है कि आप सही हैं - MySQL दृश्यों पर क्वेरी इंडेक्स का उपयोग अपनी स्रोत तालिकाओं से कर सकती है।आपके पास दृश्य पर एक इंडेक्स नहीं हो सकता है और इसलिए उन तालिकाओं में से एक से अधिक कॉलम वाले एक इंडेक्स नहीं हो सकते हैं। – thomasrutter

दुर्भाग्यवश यह नहीं बताता कि क्यों दूसरी क्वेरी MySQL द्वारा इतनी खराब अनुकूलित की गई है। मैं बस इतना सोच सकता हूं कि दृश्य वास्तव में जिस तरह से इरादा है उसमें शामिल नहीं हो रहा है। हालांकि पता नहीं है। – thomasrutter

मैंने इसमें गहराई से देखा है कि मुझे सूचना का एक प्रमुख बिंदु याद आया है :(मेरी दृश्य क्वेरी में वास्तव में एक और तालिका के साथ एक संघ है। यह दृश्य को मेर्ज एल्गोरिदम के बजाय टेम्पलेट टेबल एल्गोरिदम का उपयोग करने का कारण बन रहा है ।

अस्थायी तालिका एल्गोरिथ्म अंतर्निहित तालिकाओं में अनुक्रमित के उपयोग की अनुमति नहीं देता है।

यह MySQL में एक बग हो रहा है और जिस तरह से 2006 में वापस की सूचना मिली थी, लेकिन नहीं लगती है जैसे कि यह किया गया है 200 9 में हल! http://forums.mysql.com/read.php?100,56681,56681

ऐसा लगता है कि मुझे सिर्फ एक आउट के रूप में क्वेरी को फिर से लिखना है आर शामिल हों

स्रोत

2009-03-12 06:08:41 Alex

क्या MySQL दृश्य हमेशा पूर्ण टेबल स्कैन करता है?

उत्तर

संबंधित मुद्दे