एक MySQL डेटाबेस तालिका में रिकॉर्ड की अधिकतम संख्या


174

MySQL डेटाबेस टेबल के लिए रिकॉर्ड की ऊपरी सीमा क्या है। मैं ऑटोइन्क्रिमेंट फील्ड के बारे में सोच रहा हूं। यदि मैं रिकॉर्ड्स के मील जोड़ दूं तो क्या होगा? इस तरह की स्थितियों को कैसे संभालें? धन्यवाद!


16
1.21 GIGAWATTS का उल्लेख नहीं!
बेन

2
कम से कम यदि स्मृति कार्य करती है, तो सीमा भंडारण इंजन द्वारा निर्धारित की जाती है, इसलिए (उदाहरण के लिए) MyISAM का उपयोग करके आपको InnoDB का उपयोग करने से एक अलग सीमा मिलती है।
जेरी कॉफ़िन

77
@ प्याज-नाइट: मैं सहमत नहीं हूं। एक ही तालिका में लाखों पंक्तियों को सम्मिलित करना सामान्य है , और कुछ डेटाबेस में सीमा होती है, इसलिए यह पूछने योग्य है। यदि कोई पूछता है कि MySQL लाखों तालिकाओं का समर्थन करता है, तो यह संभवतः एक वास्तु दोष का संकेत है।
बिल कार्विन

जवाबों:


61

mysql int प्रकार काफी पंक्तियाँ कर सकते हैं: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

अहस्ताक्षरित intसबसे बड़ा मूल्य 4,294,967,295
अहस्ताक्षरित है bigintसबसे बड़ा मूल्य है18,446,744,073,709,551,615


8
2147483647 अधिकतम, इसलिए यदि आपको कई अरबों प्रविष्टियों के साथ काम करना है, तो आपको केवल आटोइनक्रीमेंट बिगिंट करना होगा? (जो कि शायद आपके चुनिंदा बयानों को तब से बहुत पहले पिघला देगा)
काज़कई

2
@Tchalvak ने हस्ताक्षरित int के लिए, कृपया mysql प्रलेखन पढ़ें।
लिएंड्रो

8
प्रश्न का संदर्भ इस बारे में है कि क्या ऑटो वेतन वृद्धि क्षेत्र बहुत सी पंक्तियों को संभाल सकता है, और अन्य संसाधनों की सीमाएं नहीं
केएम।

21
पोस्टर संख्यात्मक या किसी अन्य डेटा प्रकारों के बारे में नहीं पूछ रहा है। । मुझे वास्तव में समझ में नहीं आता है कि इसे एक सही उत्तर के रूप में कैसे चिह्नित किया जा सकता है। हालांकि मुझे यह स्वीकार करना चाहिए कि सवाल अस्पष्ट है कि हमें पीके डेटा प्रकार और एक तालिका के लिए अधिकतम पंक्तियों के बीच अंतर करना चाहिए।
बेरी

1
@ बेरी, ओपी ने इस बात का भेद किया है कि वे उनके उत्तर के रूप में इसका चयन करके क्या थे। जाहिरा तौर पर वे ऑटो वेतन वृद्धि क्षेत्र की क्षमता में रुचि रखते थे, जो मेरा उत्तर कवर करता है, न कि अन्य संसाधनों की सीमाएं।
के.एम.

238

पूर्णांक का सबसे बड़ा मूल्य आपके द्वारा तालिका में संग्रहीत की जाने वाली पंक्तियों की अधिकतम संख्या के साथ बहुत कम है।

यह सच है कि यदि आप अपनी प्राथमिक कुंजी के रूप में एक int या bigint का उपयोग करते हैं, तो आपके पास केवल अपनी प्राथमिक कुंजी के डेटा प्रकार में अद्वितीय मानों की संख्या जितनी पंक्तियाँ हो सकती हैं, लेकिन आपको अपनी प्राथमिक कुंजी को पूर्णांक बनाने की आवश्यकता नहीं है , आप इसे एक CHAR (100) बना सकते हैं। आप एक से अधिक कॉलम पर प्राथमिक कुंजी भी घोषित कर सकते हैं।

पंक्तियों की संख्या के अलावा टेबल के आकार पर अन्य अड़चनें हैं। उदाहरण के लिए, आप एक ऑपरेटिंग सिस्टम का उपयोग कर सकते हैं जिसमें फ़ाइल आकार सीमा होती है। या आपके पास एक 300GB हार्ड ड्राइव हो सकती है जो केवल 300 मिलियन पंक्तियों को संग्रहीत कर सकती है यदि प्रत्येक पंक्ति आकार में 1KB है।

डेटाबेस आकार की सीमा वास्तव में उच्च है:

http://dev.mysql.com/doc/refman/5.1/en/source-configuration-options.html

MyISAM संग्रहण इंजन प्रति तालिका 2 32 पंक्तियों का समर्थन करता है , लेकिन आप --with-big-tablesइसे तालिका में 2 64 पंक्तियों तक समर्थन करने के लिए विकल्प के साथ MySQL का निर्माण कर सकते हैं ।

http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html

InnoDB स्टोरेज इंजन में पंक्तियों की संख्या की कोई सीमा नहीं है, लेकिन इसमें 64 टेराबाइट्स के टेबल आकार की सीमा है। इसमें कितनी पंक्तियाँ फिट होती हैं यह प्रत्येक पंक्ति के आकार पर निर्भर करता है।


62
बकवास - काश मैं इससे पहले पढ़ा होता ... मैंने अपनी एक मेज पर अपने 64 टेराबाइट आकार को पार कर लिया और अब मेरी प्रणाली इतनी धीमी है!
JM4

2 ^ 32 = 4,294,967,295 और 2 ^ 64 = 18,446,744,073,709,551,615 तो ... सबसे बड़ा पूर्णांक मान पंक्तियों की अधिकतम संख्या के साथ करने के लिए थोड़ा सा है। जरूरी नहीं कि प्राथमिक कुंजी।
तेयोन

1
@ टॉम, इनोसडीबी MySQL 5.5 में डिफ़ॉल्ट भंडारण इंजन है, और 99% मामलों में बेहतर विकल्प है।
बिल करविन

2
@ Ext3h, Sphinx Search आमतौर पर MyISAM या InnoDB दोनों में फुलटेक्स्ट इंडेक्स की तुलना में बेहतर विकल्प है।
बिल करविन

1
Mysql 8 के लिए सीमा 64 केबी के पृष्ठ आकार के साथ 256 टीबी है।
बेकार

13

मेरा सुझाव है, डेटा को कभी न हटाएं। यदि तालिका 1000 से अधिक लंबी है, तो यह मत कहो कि तालिका समाप्त हो गई है। आपकी योजना में वास्तविक व्यावसायिक तर्क होना चाहिए जैसे कि यह उपयोगकर्ता कितने समय से निष्क्रिय है। उदाहरण के लिए, यदि यह 1 वर्ष से अधिक लंबा है, तो उन्हें एक अलग तालिका में रखें। आप एक धीमी गति से समय के बीच में रखरखाव स्क्रिप्ट में यह साप्ताहिक या मासिक होगा।

जब आप अपनी तालिका में कई पंक्तियों में भाग लेते हैं, तो आपको तालिकाओं को विभाजित करना या विभाजन करना शुरू कर देना चाहिए और वर्षो तक पुराने आंकड़ों जैसे कि user_2011_jan, users_2011_feb या महीने के लिए संख्याओं का उपयोग करना चाहिए। फिर इस मॉडल के साथ काम करने के लिए अपनी प्रोग्रामिंग बदलें। हो सकता है कि कम कॉलम में डेटा को सारांशित करने के लिए कम जानकारी के साथ एक नई तालिका बनाएं और फिर केवल बड़ी विभाजन तालिका का संदर्भ लें जब आपको अधिक जानकारी की आवश्यकता होती है जैसे कि जब उपयोगकर्ता अपनी प्रोफ़ाइल देख रहा हो। यह सब बहुत सावधानी से माना जाना चाहिए ताकि भविष्य में यह फिर से कारक के लिए बहुत महंगा न हो। आप केवल उन उपयोगकर्ताओं को ही शामिल कर सकते हैं जो आपकी साइट पर हर समय एक तालिका में आते हैं और वे उपयोगकर्ता जो तालिका के संग्रहित सेट में कभी नहीं आते हैं।


1
इस संबंध में, MySQL विभाजन को देखना बहुत उपयोगी है: dev.mysql.com/doc/refman/5.6/en/partitioning.html
Wim Deblauwe

10

InnoDB में, 64 टेराबाइट्स के टेबल साइज की सीमा और 65,535 की एक MySQL रो-साइज़ लिमिट के साथ 1,073,741,824 पंक्तियाँ हो सकती हैं। यह अधिकतम पंक्ति-आकार की सीमा का उपयोग करने वाले न्यूनतम रिकॉर्ड होंगे। हालाँकि, पंक्ति आकार छोटा होने पर अधिक रिकॉर्ड जोड़े जा सकते हैं।


65535 की पंक्ति-सीमा के साथ इस कई (1,073,741,824) पंक्तियों को संग्रहीत करने के लिए, हार्ड डिस्क का आकार कितना आवश्यक है? कृपया सुझाव दें
davidb

1
केवल पंक्तियों की संख्या और पंक्ति-आकार के आधार पर आवश्यक हार्ड डिस्क का आकार निर्धारित नहीं किया जा सकता है। तालिका का आकार स्वयं 64 टेराबाइट होगा। हालाँकि, TEXT और BLOB कॉलम के डेटा को पंक्ति से अलग संग्रहीत किया जाता है और इसके लिए अतिरिक्त स्थान की आवश्यकता होगी। इसके अलावा, यह TEXT और BLOB कॉलम की संख्या और प्रकार पर निर्भर करेगा क्योंकि आकार प्रकार के आधार पर भिन्न होता है। TEXT कॉलम के चार प्रकार हैं, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT। TINYBLOB, MEDIUMBLOB, BLOB और LONGBLOB नाम के चार प्रकार के BLOB कॉलम भी हैं।
जाइलो

2

Http://dev.mysql.com/doc/refman/5.6/en/features.html में स्केलेबिलिटी और लिमिट सेक्शन के अनुसार , बड़े डेटाबेस के लिए MySQL का समर्थन। वे डेटाबेस के साथ MySQL सर्वर का उपयोग करते हैं जिसमें 50 मिलियन रिकॉर्ड होते हैं। कुछ उपयोगकर्ता 200,000 तालिकाओं और लगभग 5,000,000,000 पंक्तियों के साथ MySQL सर्वर का उपयोग करते हैं।


यह मदद कर सकता है यदि आप हमें यह भी बताएं कि "वे" किस तरह के हार्डवेयर का उपयोग कर रहे हैं
मेरा खाता_राम

वास्तव में, तुम सही हो। लेकिन दुर्भाग्य से 'वे' हार्डवेयर के बारे में कुछ नहीं करते थे
डेटा

@myaccount_ram ने इसे necromance के लिए खेद है, लेकिन अगर इसके मददगार मैंने कार्रवाई में उत्पादन के कम सैद्धांतिक, अधिक व्यावहारिक सीमा MySQL को देखा है। मैंने एक डेटाबेस देखा है जो 2x db.r4.16xlarge AWS उदाहरणों (~ पाठक, 1 लेखक) पर ~ 18 बिलियन पंक्तियाँ है। प्रत्येक मशीन में 64 CPU कोर, 488GB RAM, 25Gbps नेटवर्क लिंक, 64TB डिस्क होती थी। Db का यह पैमाना CPU और डिस्क दोनों के आकार की सीमा को धक्का दे रहा था और AWS कोई बड़ा DB अनुकूलित उदाहरण प्रदान नहीं करता है। इसे एक सरल डीबी स्कीमा के साथ बदल दिया गया था जिसमें कई पंक्तियों की आवश्यकता नहीं थी।
स्काइलर ब्राउन 23

1

पंक्ति आकार सीमा

The maximum row size for a given table is determined by several factors:
  • MySQL तालिका के आंतरिक प्रतिनिधित्व में 65,535 बाइट्स की अधिकतम पंक्ति आकार सीमा होती है, भले ही भंडारण इंजन बड़ी पंक्तियों का समर्थन करने में सक्षम हो। BLOB और TEXT कॉलम केवल पंक्ति आकार सीमा की ओर 9 से 12 बाइट्स का योगदान करते हैं क्योंकि उनकी सामग्री को शेष पंक्ति से अलग संग्रहीत किया जाता है।

  • एक InnoDB तालिका के लिए अधिकतम पंक्ति आकार, जो डेटाबेस पृष्ठ के भीतर स्थानीय रूप से संग्रहीत डेटा पर लागू होता है, आधे पृष्ठ से थोड़ा कम है। उदाहरण के लिए, डिफ़ॉल्ट 16KB InnoDB पृष्ठ आकार के लिए अधिकतम पंक्ति का आकार 8KB से थोड़ा कम है, जिसे innodb_page_size कॉन्फ़िगरेशन विकल्प द्वारा परिभाषित किया गया है। " InnoDB टेबल्स पर सीमाएं "।

  • यदि वैरिएबल-लेंथ कॉलम वाली एक पंक्ति InnoDB अधिकतम पंक्ति आकार से अधिक है, तो InnoDB बाहरी ऑफ-पेज संग्रहण के लिए वैरिएबल-लेंथ कॉलम का चयन करता है, जब तक कि पंक्ति InnoDB पंक्ति आकार सीमा के भीतर फिट नहीं हो जाती। चर-लंबाई कॉलम के लिए स्थानीय रूप से संग्रहीत डेटा की मात्रा जो ऑफ-पेज संग्रहीत की जाती है, पंक्ति प्रारूप द्वारा भिन्न होती है। अधिक जानकारी के लिए, " InnoDB पंक्ति संग्रहण और पंक्ति प्रारूप " देखें।
  • अलग-अलग स्टोरेज फॉर्मेट में विभिन्न प्रकार के पेज हेडर और ट्रेलर डेटा का उपयोग किया जाता है, जो पंक्तियों के लिए उपलब्ध स्टोरेज की मात्रा को प्रभावित करता है।

1

लिंक http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

पंक्ति आकार सीमा

किसी तालिका के लिए अधिकतम पंक्ति आकार कई कारकों द्वारा निर्धारित किया जाता है:

एक MySQL तालिका के आंतरिक प्रतिनिधित्व में 65,535 बाइट्स की अधिकतम पंक्ति आकार सीमा होती है, भले ही भंडारण इंजन बड़ी पंक्तियों का समर्थन करने में सक्षम हो। BLOB और TEXT कॉलम केवल पंक्ति आकार सीमा की ओर 9 से 12 बाइट्स का योगदान करते हैं क्योंकि उनकी सामग्री को शेष पंक्ति से अलग संग्रहीत किया जाता है।

एक InnoDB तालिका के लिए अधिकतम पंक्ति आकार, जो एक डेटाबेस पेज के भीतर स्थानीय रूप से संग्रहीत डेटा पर लागू होता है, 4KB, 8KB, 16KB, और 32KB innodb_page_size सेटिंग्स के लिए आधे पेज से थोड़ा कम है। उदाहरण के लिए, डिफ़ॉल्ट 16KB InnoDB पृष्ठ आकार के लिए अधिकतम पंक्ति आकार 8KB से थोड़ा कम है। 64KB पृष्ठों के लिए, अधिकतम पंक्ति आकार 16KB से थोड़ा कम है। धारा 15.8.8, “InnoDB टेबल्स पर सीमाएं” देखें।

यदि वैरिएबल-लेंथ कॉलम वाली एक पंक्ति InnoDB अधिकतम पंक्ति आकार से अधिक है, तो InnoDB बाहरी ऑफ-पेज संग्रहण के लिए वैरिएबल-लेंथ कॉलम का चयन करता है, जब तक कि पंक्ति InnoDB पंक्ति आकार सीमा के भीतर फिट नहीं हो जाती। चर-लंबाई कॉलम के लिए स्थानीय रूप से संग्रहीत डेटा की मात्रा जो ऑफ-पेज संग्रहीत की जाती है, पंक्ति प्रारूप द्वारा भिन्न होती है। अधिक जानकारी के लिए, खंड 15.11, “InnoDB Row Storage और Row Formats” देखें।

अलग-अलग स्टोरेज फॉर्मेट में विभिन्न प्रकार के पेज हेडर और ट्रेलर डेटा का उपयोग किया जाता है, जो पंक्तियों के लिए उपलब्ध स्टोरेज की मात्रा को प्रभावित करता है।

InnoDB पंक्ति स्वरूपों के बारे में जानकारी के लिए, खंड 15.11, "InnoDB पंक्ति संग्रहण और पंक्ति प्रारूप", और धारा 15.8.3, "InnoDB तालिकाओं की भौतिक पंक्ति संरचना" देखें।

MyISAM संग्रहण स्वरूपों के बारे में जानकारी के लिए, खंड 16.2.3, “MyISAM तालिका संग्रहण प्रारूप” देखें।

http://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html


-3

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


8
उन पंक्तियों को हटाना जो आपको लगता है कि 'उपयोग से बाहर' है, खतरनाक है, और इससे समस्याएँ हल होती हैं। मेरी परियोजनाओं में से एक पिछले डेवलपर ने एक स्क्रिप्ट लागू की, जिसने तीन दिन से अधिक पुरानी शॉपिंग कार्ट को हटा दिया, यह सोचकर कि वह सही काम कर रहा है। लगता है क्या, यह साप्ताहिक मुद्दों का कारण बनता है। यदि आपको वास्तव में ज़रूरत है तो केवल डेटा हटाएं।
बेन हिचकॉक

एक बदतर स्थिति यह है जब कोई एक डेटाबेस में फ़ाइल पथ संग्रहीत करना शुरू कर देता है ... हाय, मेरी सभी परियोजना फाइलें कहां चली गईं .... मेरे पास एक छोटी सी परियोजना है जो 3.5 एम फाइलों पर शुरू होती है जो अनुमान लगाती है ... वे सभी नहीं हैं अक्सर इस्तेमाल किया।
केंड्रिक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.