8123 बाइट्स सभी के लिए पर्याप्त हैं

आज, MyISAM तालिकाओं से एक साइट को InnoDB में स्थानांतरित करने के दौरान, बाद में एक दिलचस्प विशेषता सामने आई। दो तालिकाओं के लिए इंजन को बदलने के अनुरोध ने अजीब त्रुटि "भंडारण इंजन से त्रुटि 139 प्राप्त कर ली"। इस विषय पर जानकारी के लिए खोज करने के बाद, यह पाया गया कि यह त्रुटि तब होती है जब MySQL के साथ काम करने वाली स्मृति तालिका के आधे हिस्से में तालिका की कोई भी पंक्ति फिट नहीं होती है। ये पृष्ठ 16 Kb, और आधे हैं, इसलिए, 8 Kb।

अपने आप में प्रतिबंध अजीब है, लेकिन पहली नज़र में इसे हासिल करना मुश्किल लगता है, क्योंकि जैसा कि आप जानते हैं, MySQL स्टोर टेबल से अलग भंडारण में पाठ डेटा संग्रहीत करता है। यह पता चला कि यह केवल आधा सच है। वास्तव में, InnoDB एक अलग स्टोरेज में केवल "अधिशेष" स्टोर करता है, जिसमें यह प्रत्येक टेक्स्ट फ़ील्ड के पहले 768 बाइट्स को शामिल नहीं करता है। यानी कोई भी टेक्स्ट लाइन बाइट से उतने बाइट्स खाएगा जितना इसमें शामिल है, लेकिन 768 से अधिक नहीं है। यह गणना करना आसान है कि 768 बाइट्स से अधिकतम टेक्स्ट फ़ील्ड जो एक तालिका में सुरक्षित रूप से संग्रहीत की जा सकती है। 10. और वास्तव में, यदि आप उदाहरण चलाते हैं , तो यह है आसानी से जाएगा। लेकिन यह कम से कम एक क्षेत्र की संख्या बढ़ाने के लायक है, और हमें शुरुआत में भी यही त्रुटि मिलेगी।

सबसे हड़ताली बात यह है कि बाधा, या यहां तक ​​कि स्ट्रिंग डेटा प्रकारों की "लोलुपता" की बेरुखी नहीं है, लेकिन इस समस्या की चुप्पी। InnoDB से सैकड़ों टेक्स्ट फ़ील्ड के साथ टेबल बनाना आसान हो जाता है। उसी समय, आप वास्तविक डेटा के साथ तालिका को भरते समय उन्हें केवल उत्पादन में उपयोग करने में सक्षम नहीं होंगे। एक स्लेटेड एरर मैसेज कुछ सकारात्मक भावनाओं को भी छोड़ देता है।

बीमारी से निपटने के दो तरीके हैं:

बढ़ती UNIV_PAGE_SIZE ( जारी ) के साथ पुन: संयोजन।

बारकोडा फ़ाइल प्रारूप का समर्थन करने वाले एक प्लगइन के माध्यम से InnoDB को जोड़ना और तालिकाओं के ROW_FORMAT को डायनेमिक में बदलना। या यदि आप पहले से ही MySQL 5.5 है तो ROW_FORMAT = डायनामिक का उपयोग करें।