संभावित कथन का उपयोग न करें SELECT कथन

Question

मेरे पास एक विरासत प्रणाली से एक सारणी है जिसमें प्राथमिक कुंजी नहीं है। यह कारखाने में सामग्री जारी करने के लिए लेनदेन संबंधी डेटा रिकॉर्ड करता है।

सादगी के लिए, मान लें कि प्रत्येक पंक्ति में job_number, part_number, मात्रा & date_issued है।

मैंने जारी किए गए कॉलम की तारीख में एक इंडेक्स जोड़ा। जब मैं एक issued_parts से व्याख्या चुनें * कहां date_issued> '20100101', यह इस से पता चलता चलाएँ:

 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| id | select_type | table   | type | possible_keys  | key | key_len | ref | rows | Extra  | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| 1 | SIMPLE  | issued_parts | ALL | date_issued_alloc | NULL | NULL | NULL | 9724620 | Using where | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 

तो यह कुंजी देखता है, लेकिन यह इसका इस्तेमाल नहीं करता है? क्या कोई समझा सकता है क्यों?

Answer 1

कुछ मुझे बताता है कि MySQL क्वेरी ऑप्टिमाइज़र सही तरीके से निर्णय लेता है।

यहां बताया गया है कि आप कैसे बता सकते हैं। इन चलाएँ:

पंक्तियाँ की गणना

SELECT COUNT(1) FROM issued_parts; 

आपका क्वेरी

SELECT COUNT(1) FROM issued_parts WHERE date_issued > '20100101'; 

मिलान पंक्तियाँ पंक्तियों आप वास्तव में पुन: प्राप्त करने की संख्या तालिका कुल संख्या, MySQL के 5% से अधिक है की गणना क्वेरी ऑप्टिमाइज़र का फैसला है कि यह एक पूर्ण टेबल स्कैन करने के लिए कम प्रयास होगा।

अब, अगर आपकी क्वेरी अधिक सटीक, उदाहरण के लिए, इस के साथ था:

SELECT * FROM issued_parts WHERE date_issued = '20100101'; 

तो, आप एक अलग योजना पूरी तरह व्याख्या मिल जाएगा।

Answer 2

possible_keys प्रासंगिक कॉलम के साथ नाम कुंजी, लेकिन इसका मतलब यह नहीं है कि इसमें प्रत्येक कुंजी क्वेरी के लिए उपयोगी होगी। इस मामले में, कोई नहीं हैं।

Answer 3

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

दूसरी तरफ, बी-ट्री इंडेक्स आपकी मदद कर सकता है क्योंकि यह उन तत्वों को ऑर्डर देता है जो यह अनुक्रमणित कर रहे हैं। उदाहरण के लिए, यहां देखें: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html mysql के लिए (बी-ट्री इंडेक्स लक्षणों की खोज करें)। आप यह जांचना चाह सकते हैं कि आपकी तालिका इसके सूचकांक कॉलम के लिए बी-पेड़ इंडेक्स का उपयोग कर रही है।