इसे वास्तव में मापना होगा, हम जो जानते हैं, और जो हम मानते हैं उसके आधार पर हम कुछ "अनुमान" बना सकते हैं, लेकिन वे केवल अनुमान हैं।
आप यह उल्लेख नहीं करते हैं कि यह तालिका InnoDB है, या MyISAM गतिशील पंक्तियों के साथ है, या MyISAM निश्चित लंबाई पंक्तियों के साथ है। इससे कुछ फर्क पड़ेगा।
लेकिन आपके द्वारा पोस्ट किए गए मानों के लिए, '961637593864109_412954765521130' (31 वर्ण), यह मानते हुए कि आप एकल बाइट वर्णसेट (उदा. लैटिन1) का उपयोग कर रहे हैं, या एक वर्ण सेट जो उन विशेष वर्णों को एकल बाइट में एन्कोड करता है (उदा. utf8)...
InnoDB और MyISAM गतिशील प्रारूप के लिए, उस पंक्ति के लिए 31+1-8=24 अतिरिक्त बाइट्स हैं। (BIGINT 8 बाइट्स में फिट बैठता है, 31 वर्णों का VARCHAR(31) मान 32 बाइट्स का उपयोग करेगा।)
निश्चित लंबाई वाली पंक्तियों वाली MyISAM तालिका के लिए, यह प्रति पंक्ति 23 बाइट्स का अंतर होगा। (स्थान सभी 31 वर्णों के लिए आरक्षित है, और लंबाई को संग्रहीत करने की आवश्यकता नहीं है।)
वह प्राथमिक कुंजी मान भी प्रत्येक अनुक्रमणिका में दोहराया जाएगा, इसलिए प्रत्येक अनुक्रमणिका के साथ स्थान भी बढ़ा है।
यह मानते हुए कि आपकी तालिका पंक्तियाँ BIGINT का उपयोग करके 120 बाइट्स हैं, और पंक्तियाँ VARCHAR के साथ 144 बाइट्स हैं, यह एक 20% है बढ़ोतरी। आपकी पंक्तियाँ जितनी बड़ी होंगी, प्रतिशत वृद्धि उतनी ही कम होगी, और इसके विपरीत।
1,000,000 पंक्तियों के लिए (मैं इसलिए "वन मील्युन रो" कहना चाहता हूं, जिस तरह से डॉ। ईविल अपनी पिंकी उंगली को इस मुंह के कोने में रखते हैं और कहते हैं "दस लाख डॉलर") कि अतिरिक्त 24 बाइट्स प्रति पंक्ति कुल लगभग 24 एमबी है।
लेकिन यह वास्तव में इतना आसान नहीं है। InnoDB स्थान के संदर्भ में, यह एक बात है कि पंक्तियाँ एक ब्लॉक में "फिट" कैसे हो सकती हैं। औसत पंक्ति का आकार जितना बड़ा होगा, ब्लॉक में उतनी ही अधिक खाली जगह होगी।
यदि आप पंक्तियों को डिस्क पर संग्रहीत करने के अलावा कुछ नहीं करते हैं, तो यह वास्तव में डिस्क स्थान में वृद्धि, और बैकअप के लिए अतिरिक्त समय और स्थान है।
यदि "144 बाइट" पंक्तियों की एक ही संख्या "120 बाइट" पंक्तियों के रूप में एक ब्लॉक में फिट होती है, तो आपको अंतरिक्ष में कोई अंतर नहीं दिखाई देगा। लेकिन अगर किसी ब्लॉक में कम पंक्तियाँ फिट होती हैं, तो वह है अधिक ब्लॉक, InnoDB बफर पूल में अधिक स्थान, अधिक i/o, आदि।
एकल पंक्ति के प्रश्नों के लिए, या तो प्राथमिक कुंजी मान द्वारा, या किसी अन्य अद्वितीय अनुक्रमणिका लुकअप द्वारा, अंतर नगण्य होने वाला है।
यदि आप बड़े परिणामों के साथ काम कर रहे हैं, तो वह परिणाम सेट तैयार करने के लिए अतिरिक्त मेमोरी है, और क्लाइंट को स्थानांतरित करने के लिए अतिरिक्त बाइट्स, आदि।
यदि VARCHAR कुंजी को इस तरह से डिज़ाइन किया गया है कि पंक्तियों के "समूह" को एक साथ एक्सेस किया जाता है, तो कुंजी मान का एक ही प्रमुख भाग होता है, तो InnoDB के साथ, वास्तव में कुछ प्रदर्शन सुधार हो सकता है। ऐसा इसलिए है क्योंकि प्राथमिक कुंजी क्लस्टर कुंजी है... किसी क्वेरी को संतुष्ट करने के लिए आवश्यक पंक्तियों की बेहतर संभावना एक ही ब्लॉक में है, न कि ब्लॉकों के एक समूह में फैली हुई है।
इसका विलोम यह है कि यदि इन्सर्ट और डिलीट का प्रदर्शन किया जाता है, तो कुछ ब्लॉकों में अधिक खाली स्थान होगा। (हटाए जाने के साथ, हटाए गए पंक्तियों के लिए स्थान ब्लॉक में रहता है; इसे पुन:उपयोग करने के लिए, आपको एक पंक्ति डालने की आवश्यकता होगी जिसमें समान कुंजी मान हो (या कम से कम एक महत्वपूर्ण मान इतना करीब हो कि वह उसी ब्लॉक में उतरे ।) और रैंडम इन्सर्ट के साथ, हम ब्लॉक स्प्लिट्स प्राप्त करने जा रहे हैं।
