- आपके द्वारा बताए गए ओवरहेड से अधिक है। 20 बाइट्स/पंक्ति हो सकता है करीब बनें ।
- विश्वास न करें
SHOW TABLE STATUS"पंक्तियाँ" देने के लिए,SELECT COUNT(*) .... का उपयोग करें ध्यान दें कि यह लगभग 2 के कारक से कैसे दूर था। - दूसरे तरीके से गणना करें:135245332480 / 3017513240 =45 बाइट्स।
- 45 बाइट्स से, मैं यह निष्कर्ष निकालता हूं कि बहुत सारी कोशिकाएं NULL हैं?
- प्रत्येक पंक्ति के प्रत्येक कॉलम में 1- या 2-बाइट ओवरहेड होता है।
ROW_FORMATमायने रखता है।TEXTऔरBLOB(आदि) साधारण डेटाटाइप की तुलना में मौलिक रूप से भिन्न नियम हैं।- अनुक्रमणिका आपके द्वारा बताए गए 6 बाइट्स से बहुत अधिक लेती है (अपना अन्य पोस्टिंग )।
- Btree संरचना में कुछ ओवरहेड है। क्रम में लोड होने पर, प्रत्येक ब्लॉक का 15/16 भरा जाता है (जिसका उल्लेख डॉक्स में कहीं किया गया है)। मंथन के बाद, रेंज आसानी से 50-100% भर सकती है; a BTree 69% पूर्ण (इसलिए अन्य पोस्टिंग में 1.45) की ओर बढ़ता है।
बैकअप के लिए समान मात्रा में स्थान आरक्षित करना...
- मुझे नहीं पता कि वे ऐसा क्या कर रहे हैं।
- यदि वे mysqldump (या समान) का उपयोग करते हैं, तो यह एक सुरक्षित सूत्र नहीं है -- पाठ डेटाबेस का डंप काफी बड़ा या छोटा हो सकता है।
- यदि वे LVM का उपयोग करते हैं, तो उनके पास पूर्ण बाइनरी डंप के लिए जगह है। लेकिन गाय के कारण इसका कोई मतलब नहीं है।
- (इसलिए, मैं Q3 को छोड़ देता हूं।)
क्या क्लाउड सेवा किसी प्रकार का संपीड़न कर रही है?
