एक नियमित int पर एक mysql तालिका में एक छोटा सा डेटाटाइप का उपयोग करना वास्तव में स्मृति उपयोग में सुधार करता है? क्या हार्डवेयर सभी डेटा के लिए अभी भी एक पूर्ण 64 बिट शब्द आकार आवंटित नहीं करेगा? यदि यह एक पूर्ण शब्द आवंटित नहीं करता है, तो क्या हम स्मृति में आवंटित 64 बिट शब्द से कई छोटे-छोटे या छोटे-छोटे हिस्सों को पार करने से प्रदर्शन में कमी नहीं देख पाएंगे?mysql में int पर छोटे से डेटाटाइप का उपयोग करना वास्तव में स्मृति को बचाता है?
असल में, क्या इसके बाद निम्न तालिका का उपयोग करने के लिए कोई डिज़ाइन/मेमोरी/प्रदर्शन लाभ है, यह मानते हुए कि हम जानते हैं कि Status
कॉलम में संग्रहीत मानों की सीमा कभी भी छोटी/न्यूनतम सीमा से अधिक नहीं होगी? किसी भी अंतर्दृष्टि की सराहना की जाएगी:
create table `TestTableWithSmallInt` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`Status` smallint(11) DEFAULT 0,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
create table `TestTableWithInt` (
`ID` bigint(20) NOT NULL AUTO_INCREMENT,
`Status` int(11) DEFAULT 0,
PRIMARY KEY (`ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
शायद यह हार्डवेयर हार्डवेयर से अधिक है? 64 बिट आर्किटेक्चर की मेरी समझ यह है कि यहां तक कि सबसे छोटा संभव मूल्य भी 64 बिट शब्द का आकार लेगा। यदि ऐसा है, तो क्या एक छोटा सा अभी भी एक बिट के रूप में स्मृति के समान 64 बिट खंड का उपयोग नहीं करेगा? इतनी प्रभावी ढंग से, एक फ़ील्ड को छोटा करने के रूप में घोषित करने से वास्तव में किसी भी स्मृति को सहेजे बिना, क्षेत्र पर अधिकतम मूल्य लगाया जाएगा? रास्ते से नंगे प्रकार घोषित करने की सलाह के लिए धन्यवाद :) – encrest
ऐसा नहीं है। हो सकता है कि आप संरेखण के मुद्दों के बारे में सोच रहे हों, लेकिन 16-बिट मान [4-बाइट सीमाओं पर गठबंधन] हैं (http://software.intel.com/en-us/articles/data-alignment-when-migrating-to- 64-बिट-इंटेल-आर्किटेक्चर) 8 नहीं। मैं वास्तव में इस बारे में चिंता नहीं करता जबतक कि आप माईएसक्यूएल के मेमोरी पदचिह्न को सार्थक तरीके से माप नहीं सकते हैं, और मुझे कभी भी उस स्तर के विस्तार से खुद को चिंता नहीं करनी पड़ी। कंप्यूटर में मेगाबाइट्स मेमोरी है, और डेटा को अधिक कसकर पैक करने के अनुकूलन हैं, यह शायद ही कभी चिंता का विषय है। – tadman