औसत पंक्ति की लंबाई अपेक्षा से 4 गुना बड़ी क्यों है?

औसत पंक्ति आकार के अधिक होने के कई कारण हैं।

• यह एक सन्निकटन है। (मैंने पाया है कि यह आम तौर पर 2x-3x ऊंचा होता है।) एक चरम मामले में - तालिका में एक पंक्ति - यह प्रति पंक्ति 16384 बाइट्स का दावा करेगी। वह एक InnoDB ब्लॉक है। तालिका में पंक्तियों की संख्या अनुमानित है . पंक्तियों के लिए उपयोग किया जाने वाला डिस्क स्थान सटीक है, लेकिन नीचे ओवरहेड देखें। औसत पंक्ति आकार उन दोनों का भागफल है।

• प्रति कॉलम ओवरहेड -- 1 या 2 बाइट्स

• ओवरहेड प्रति पंक्ति -- 20-30 बाइट्स -- लेन-देन को संभालने के लिए, एक ब्लॉक में पंक्तियों को खोजने के लिए, आदि

• प्रति ब्लॉक ओवरहेड -- प्रति 16KB ब्लॉक में कुछ बाइट्स

• बीट्री में थ्रैशिंग के लिए ओवरहेड - मिनट एक ब्लॉक का लगभग 1/16 है, अधिकतम आधा ब्लॉक है, बहुत सारे डिलीट और/या रैंडम इंसर्ट के बाद औसत लगभग 30% है।

• डिस्क स्थान के पूर्व-आवंटन के लिए ओवरहेड (1MB? 8MB?)

• जैसे-जैसे तालिका एक ब्लॉक में फ़िट होने से बढ़ती है, लेआउट एल्गोरिथम बदल जाता है, और ओवरहेड का प्रतिशत अस्थायी रूप से बढ़ जाता है।

• हटाई गई पंक्तियाँ OS में अपना स्थान नहीं लौटाती हैं, इसलिए फ़ाइल का आकार स्थिर रहता है, जिससे स्पष्ट बढ़ जाता है पंक्ति का आकार।

• यदि आपके पास स्पष्ट PRIMARY KEY नहीं है या एक UNIQUE कुंजी जिसे पीके में प्रचारित किया जा सकता है, तो पीके के लिए एक दुर्गम रूप से 6-बाइट फ़ील्ड (प्रति पंक्ति) है।

• बड़ा TEXT /BLOB और यहां तक ​​कि VARCHAR "ऑफ-रिकॉर्ड" संग्रहीत हैं। यह गणनाओं को बहुत जटिल करता है। और यह 4 ROW_FORMATs . में से किस पर निर्भर है आप उपयोग कर रहे हैं। कुछ मामलों में ऐसे प्रत्येक सेल के लिए 20-बाइट "पॉइंटर" होता है।

• FOREIGN KEY बाधाएं आवश्यक स्थान में नहीं जुड़ती हैं, सिवाय इसके कि वे हो सकता है एक अनुक्रमणिका बनाने के लिए बाध्य करें।

• INDEXes , PRIMARY KEY . के अलावा avg_row_length में शामिल नहीं हैं।

• PRIMARY KEY आमतौर पर डेटा . में बहुत कम ओवरहेड शामिल होता है बीट्री। अंगूठे का एक साधारण नियम 1% ओवरहेड है (स्तंभ के शीर्ष पर, स्वयं)। यह ओवरहेड बीट्री का नॉन-लीफ नोड है।

• जबकि एक InnoDB लेनदेन व्यस्त है, किसी भी संशोधित पंक्तियों को "इतिहास सूची" में रखा जाता है। यह अधिक ओवरहेड की ओर जाता है।

• (पूरी तरह से संबंधित नहीं)। InnoDB का COMPRESSED समस्याएँ हैं -- यह केवल 2x संपीड़न देता है, 3x के विशिष्ट पाठ संपीड़न के विपरीत। एक ही समय में (कम से कम कुछ ब्लॉक के लिए) बफर_पूल में संपीड़ित और असम्पीडित दोनों डेटा की आवश्यकता के कारण इसमें कुछ रैम खर्च होती है।

SHOW TABLE STATUS और information_schema.TABLES . से प्राप्त करना वही डेटा देता है। कुछ . प्राप्त करने के तरीके हैं डेटा और प्रत्येक तालिका के लिए B+ट्री की गहराई में अंतर्दृष्टि।