"मैसुकल रो आकार बहुत बड़ा" के लिए सीमा बदलें

Question

मैं सीमा कैसे बदल सकता हूं

पंक्ति का आकार बहुत बड़ा (> 8126)। कुछ कॉलम को TEXT या BLOB में बदलने या उपयोग ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSEDकरने से मदद मिल सकती है। वर्तमान पंक्ति प्रारूप में, BLOB768 बाइट्स के उपसर्ग को इनलाइन संग्रहित किया जाता है।

तालिका:

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
top_a   varchar(255)    No       
top_b   varchar(255)    No       
top_c   varchar(255)    No       
top_d   varchar(255)    No       
top_e   varchar(255)    No       
top_f   varchar(255)    No       
top_g   varchar(255)    No       
top_h   varchar(255)    No       
top_i   varchar(255)    No       
top_j   varchar(255)    No       
top_title_a varchar(255)    No       
top_title_b varchar(255)    No       
top_title_c varchar(255)    No       
top_title_d varchar(255)    No       
top_title_e varchar(255)    No       
top_title_f varchar(255)    No       
top_title_g varchar(255)    No       
top_title_h varchar(255)    No       
top_title_i varchar(255)    No       
top_title_j varchar(255)    No       
top_desc_a  text    No       
top_desc_b  text    No       
top_desc_c  text    No       
top_desc_d  text    No       
top_desc_e  text    No       
top_desc_f  text    No       
top_desc_g  text    No       
top_desc_h  text    No       
top_desc_i  text    No       
top_desc_j  text    No       
status  int(11) No       
admin_id    int(11) No 

Comments

क्या Noप्रदर्शित किया जा रहा है?

— hjpotter92

"पंक्ति आकार बहुत बड़ा (> 8126) त्रुटि को अपडेट नहीं कर सकता है। कुछ कॉलमों को TEXT या BLOB में बदलकर या ROW_FORMAT = DYNAMIC या ROW_FORMAT = COMPRESSED का उपयोग करने में मदद मिल सकती है। वर्तमान पंक्ति प्रारूप में, 768 बाइट्स का BLOB उपसर्ग इनलाइन संग्रहीत है।"

— लशा कर्ट

क्या आप अपनी पोस्ट में कुछ अन्य विवरण जोड़ सकते हैं, कम से कम टिप्पणी के रूप में?

— ईनेकी

यदि यह डेटा किसी अन्य तालिका में है, तो इसके बजाय किसी विदेशी कुंजी का उपयोग करने पर विचार करें, यह नाटकीय रूप से आपके पंक्ति आकार को कम करेगा, और आपके डेटाबेस स्कीमा को सामान्य करेगा।

— १३:३३

@AL: उफ़, आप सही हैं - अन्य वोट पर करीबी वोट

— डालिए

Answer 1

सर्वरफॉल्ट पर भी सवाल पूछा गया है।

आप इस लेख पर एक नज़र डालना चाह सकते हैं जो MySQL पंक्ति आकारों के बारे में बहुत कुछ बताता है। यह ध्यान रखना महत्वपूर्ण है कि भले ही आप TEXT या BLOB फ़ील्ड का उपयोग करते हों, फिर भी आपकी पंक्ति का आकार 8K (InnoDB के लिए सीमा) से अधिक हो सकता है क्योंकि यह पृष्ठ में प्रत्येक फ़ील्ड इनलाइन के लिए पहले 768 बाइट्स संग्रहीत करता है।

इसे ठीक करने का सबसे सरल तरीका है , InnoDB के साथ बाराकुडा फ़ाइल प्रारूप का उपयोग करना । यह मूल रूप से समस्या से छुटकारा दिलाता है केवल 20 बाइट पॉइंटर को टेक्स्ट डेटा में संग्रहीत करने के बजाय पहले 768 वॉइट्स को संग्रहीत करने के द्वारा।

---

ओपी के लिए काम करने की विधि इस प्रकार थी:

1. अनुभाग के my.cnfतहत फ़ाइल में निम्न जोड़ें [mysqld]।

   innodb_file_per_table=1
   innodb_file_format = Barracuda
   

2. ALTERउपयोग करने के लिए मेज ROW_FORMAT=COMPRESSED।

   ALTER TABLE nombre_tabla
       ENGINE=InnoDB
       ROW_FORMAT=COMPRESSED 
       KEY_BLOCK_SIZE=8;
   

---

एक संभावना है कि उपरोक्त अभी भी आपके मुद्दों को हल नहीं करता है। यह InnoDB इंजन के साथ एक ज्ञात (और सत्यापित) बग है , और अस्थायी भंडारण के रूप में अभी के लिए MyISAM इंजन को वापस करना है । तो, आपकी फ़ाइल में:my.cnf

internal_tmp_disk_storage_engine=MyISAM

Comments

+1 -> innodb_file_per_table भाग महत्वपूर्ण है और बारकुडा के प्रारूप को बदलने के साथ हाथ से जाता है। इसके बिना, MySQL चुपचाप एंटेलोप का उपयोग करना जारी रखेगा।

— निक

@Eduardo मैं पहले डेटा का बैकअप लेने की सलाह दूंगा। लेकिन हाँ, आप उत्पादन पर भी ऐसा कर सकते हैं!

— hjpotter92

innodb_file_per_table=1इस विकल्प को सक्रिय करने के लिए उपयोग करें ।

— स्टिजेन ज्युकेंस 13

यह समस्या को ठीक करने की गारंटी नहीं है। इस पोस्ट को एक उदाहरण स्क्रिप्ट के लिए देखें जो इन सेटिंग्स को जोड़ता है लेकिन फिर भी त्रुटि को पुन: उत्पन्न करने में सक्षम है।

— सेरिन

@ user1183352 मेरे उत्तर के ऊपर अद्यतन करें। इस में गहराई से गोता लगाने के लिए मुझे फिर से याद दिलाने के लिए धन्यवाद। :)

— hjpotter92

Answer 2

मैं हाल ही में इस समस्या में भाग गया और इसे एक अलग तरीके से हल किया। यदि आप MySQL संस्करण 5.6.20 चला रहे हैं तो सिस्टम में एक ज्ञात बग है। MySQL डॉक्स देखें

बग के कारण महत्वपूर्ण # 69477, बड़े, बाहरी रूप से संग्रहीत BLOB फ़ील्ड्स के लिए रीडू लॉग लिखता है जो हाल ही की सबसे चौकी को अधिलेखित कर सकता है। इस बग को संबोधित करने के लिए, MySQL 5.6.20 में पेश किया गया पैच redo log के आकार को सीमित करता है BLOB लिखता है 10% redo फ़ाइल आकार। इस सीमा के परिणामस्वरूप, innodb_log_file_size को आपकी तालिकाओं की पंक्तियों में पाए जाने वाले सबसे बड़े BLOB डेटा आकार से 10 गुना अधिक मूल्य पर सेट किया जाना चाहिए, साथ ही अन्य चर लंबाई फ़ील्ड (VARCHAR, VAMBINARY और TEXT प्रकार फ़ील्ड) की लंबाई।

मेरी स्थिति में अपमानजनक बूँद तालिका 16MB के आसपास थी। इस प्रकार, जिस तरह से मैंने इसे हल किया था वह my.cnf के लिए एक पंक्ति जोड़कर था जो यह सुनिश्चित करता था कि मेरे पास कम से कम 10x राशि है और फिर कुछ हैं:

innodb_log_file_size = 256M

Comments

सटीक। पैरामीटर longblobबढ़ाते ही किसी फ़ील्ड पर मेरा "रो साइज़ बहुत बड़ी" त्रुटि गायब हो गई innodb_log_file_size। साथ ही 5.6.20 चल रहा था।

— adamup

धन्यवाद। होमब्रीव 5.6.21 पर चल रहा था, परम को बदलकर समस्या को ठीक कर दिया।

— नानोमैन

इस त्रुटि को ठीक करने के लिए मुझे और @ hjpotter92 के उत्तर दोनों की आवश्यकता थी।

— सेरिन

धन्यवाद। 5.6.21 पर चल रहा था और इस समाधान से मदद मिली।

— पेटियार

इससे मेरा मसला हल नहीं हुआ। मैं अपने कई VARCHAR क्षेत्रों को TEXTs में बदलने पर विचार कर रहा हूं, जैसा कि मैंने इसी तरह के धागों पर देखा है।

— पीडीरिया

Answer 3

अपने my.cnf फ़ाइल पर अनुसरण सेट करें और mysql सर्वर को पुनरारंभ करें।

innodb_strict_mode=0

Comments

innodb_strict_mode=0-> कोई रिक्त स्थान नहीं। अन्यथा, mariaDB 10.2 को फिर से शुरू करने में त्रुटि होती है :-P

— Pathros

मैंने mariadb के साथ प्रयास नहीं किया, MySQL के लिए इसे रिक्त स्थान निकालने की आवश्यकता नहीं है।

— कार्ल

प्रलेखन के अनुसार, सख्त मोड को अक्षम करने से केवल क्षरण और चेतावनी को प्रकट होने से रोकता है, इसलिए यह समस्या को हल करने में नहीं लगता है! download.nust.na/pub6/mysql/doc/innodb-plugin/1.1/en/…

— João Teixeira

यह काम करने लगता है और मुझे बिना किसी समस्या के तालिकाएँ बनाने और डेटा संग्रहीत करने देता है

— क्रिस मुइंच

@ जोआओ, यह और अधिक करता है .. dev.mysql.com/doc/refman/8.0/en/…

— कार्ल

Answer 4

यदि आप इंजन को स्विच कर सकते हैं और InnoDB के बजाय MyISAM का उपयोग कर सकते हैं, तो इससे मदद मिलनी चाहिए:

ENGINE=MyISAM

MyISAM के साथ दो चेतावनी हैं (यकीनन अधिक):

1. आप लेन-देन का उपयोग नहीं कर सकते।
2. आप विदेशी कुंजी बाधाओं का उपयोग नहीं कर सकते।

Comments

यदि आप लेनदेन और विदेशी प्रमुख बाधाओं के बिना जाने का मन नहीं करते हैं तो ठीक है। लेकिन इस बात से अवगत रहें कि आप MyISAM पर स्विच करते समय इन्हें ढीला कर देते हैं।

— wobbily_col

यह सलाह पागल है - कम से कम वाक्यांशों में यह चेतावनी देगा! लेन-देन और अग्रगामी मुख्य अड़चनें इस प्रारूप की सबसे कम समस्याएं हैं!

— हसन सैयद

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

— रेमो वेन्ड्ट

और MyISAM दूर जा रहा है।

— रिक जेम्स

मेरे लिए काम किया। मेरे मामले में मेरे पास 300 से अधिक क्षेत्र थे जिनमें से प्रत्येक की लंबाई 10 थी। मेरा इस तालिका में कोई संबंध नहीं है इसलिए MyISAM पर स्विच करना ठीक था।

— रॉबर्ट सायलर

Answer 5

मैं एक भयानक जवाब साझा करना चाहूंगा, यह मददगार हो सकता है। क्रेडिट बिल करविन यहां देखें /dba/6598/innodb-create-table-error-row-size-too-large

वे InnoDB फ़ाइल प्रारूप द्वारा भिन्न होते हैं। वर्तमान में एंटेलोप और बाराकुडा नामक 2 प्रारूप हैं।

केंद्रीय टेबलस्पेस फ़ाइल (ibdata1) हमेशा एंटेलोप प्रारूप में होती है। यदि आप फ़ाइल-प्रति-तालिका का उपयोग करते हैं, तो आप my.cnf में innodb_file_format = Barracuda सेट करके व्यक्तिगत फ़ाइलों का उपयोग बाराकुडा प्रारूप में कर सकते हैं।

मूल बिंदु:

1. InnoDB डेटा के एक 16KB पृष्ठ में डेटा की कम से कम दो पंक्तियाँ होनी चाहिए। साथ ही प्रत्येक पृष्ठ में एक हेडर और एक पाद लेख होता है जिसमें पृष्ठ चेकसम और लॉग अनुक्रम संख्या और इसी तरह होता है। यही कारण है कि आपको प्रति पंक्ति 8KB से थोड़ा कम की सीमा मिलती है।

2. निश्चित आकार के डेटा प्रकार जैसे INTEGER, DATE, FLOAT, CHAR को इस प्राथमिक डेटा पेज पर संग्रहीत किया जाता है और पंक्ति आकार सीमा की गणना की जाती है।

3. चर-आकार के डेटा प्रकार जैसे VARCHAR, TEXT, BLOB को ओवरफ्लो पृष्ठों पर संग्रहीत किया जाता है, इसलिए वे पंक्ति आकार सीमा की पूरी तरह से गणना नहीं करते हैं। एंटेलोप में, ऐसे स्तंभों के 768 बाइट्स को ओवरफ्लो पृष्ठ पर संग्रहीत किए जाने के अलावा प्राथमिक डेटा पृष्ठ पर संग्रहीत किया जाता है। बाराकुडा एक गतिशील पंक्ति प्रारूप का समर्थन करता है, इसलिए यह प्राथमिक डेटा पृष्ठ पर केवल 20-बाइट सूचक को संग्रहीत कर सकता है।

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

बाराकुडा एक ROW_FORMAT = अतिप्रवाह डेटा के लिए आगे भंडारण क्षमता हासिल करने के लिए तैयार का भी समर्थन करता है।

मुझे यह भी टिप्पणी करनी होगी कि मैंने कभी डिज़ाइन की गई तालिका को पंक्ति आकार सीमा से अधिक नहीं देखा है। यह एक मजबूत "कोड गंध" है जिसे आप पहले सामान्य रूप के दोहराए जाने वाले समूहों की स्थिति का उल्लंघन कर रहे हैं।

Answer 6

मैं एक ही मुद्दा था, यह मेरे लिए हल:

ALTER TABLE `my_table` ROW_FORMAT=DYNAMIC;

MYSQL प्रलेखन से :

डायनामिक पंक्ति प्रारूप पूरी पंक्ति को अनुक्रमणिका नोड में रखने की दक्षता को बनाए रखता है यदि यह फिट बैठता है (जैसा कि COMPACT और REDUNDANT प्रारूप करते हैं), लेकिन यह नया प्रारूप बड़ी संख्या में डेटा बाइट्स के साथ बी-ट्री नोड्स को भरने की समस्या से बचा जाता है। लंबे कॉलम। डायनामिक प्रारूप इस विचार पर आधारित है कि यदि लंबे डेटा मान के एक हिस्से को ऑफ-पेज संग्रहीत किया जाता है, तो यह आमतौर पर सभी ऑफ-पेज को स्टोर करने के लिए सबसे अधिक कुशल होता है। डायनामिक प्रारूप के साथ, छोटे कॉलम बी-ट्री नोड में बने रहने की संभावना है, किसी भी पंक्ति के लिए आवश्यक अतिप्रवाह पृष्ठों की संख्या कम से कम।

Comments

... लेकिन आपको एक अलग फ़ाइल प्रारूप की आवश्यकता है, इसलिए यू पहले से ही बाराकुडा में हैं? क्योंकि मुझे उस कमांड को आज़माने में एक त्रुटि मिलती है, कहते हैंWarnings from last query: InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope

— टेड

जब मैंने HeidiSQL को अपने अंतर्निहित GUI के माध्यम से एक ही कमांड चलाने दिया, तो यह किसी भी तरह सफल रहा, लेकिन यह बिल्कुल भी मदद नहीं करता, मुझे एक ही त्रुटि मिलती है,Row size too large (>8126)

— Ted

Inn.inb_file_format = Barracuda को my.ini में सेट करने का प्रयास करें और अन्य तालिका my_tableROW_FORMAT = डायनामिक को आज़माएँ; फिर से

— मल्टीमीडियाएक्स

हाँ, मुझे लगता है कि मैंने वास्तव में आखिर में क्या किया, और मुझे लगता है कि इसे हल कर दिया। लेकिन मैंने हताशा में एक ही समय में TEXT में बहुत सारे कॉलम बदल दिए =) Thx हालांकि, मुझे वास्तव में लगता है कि यह था।

— टेड

अच्छा !, यदि आपको लगता है कि यह एक अच्छा जवाब है, तो इसे वोट दें और मान्य प्रतिक्रिया के रूप में स्वीकार करें, धन्यवाद!

— मल्टीमीडियाएक्स

Answer 7

घंटों बिताने के बाद मैंने इसका हल ढूंढा है: टेबल को MyISAM में बदलने के लिए बस अपने SQL को MySQL एडमिन में चलाएं:

USE db_name;
ALTER TABLE table_name ENGINE=MYISAM;

Comments

यदि समस्या एक तालिका तालिका कथन में हो रही है तो बहुत मदद नहीं करता है।

— मार्क फ्रेजर

create tableएक ही विकल्प है:CREATE TABLE ... ENGINE=MyISAM ...

— xebeche

Answer 8

मैं इस मुद्दे में भाग गया जब मैं एक अलग सर्वर से एक समर्थित mysql डेटाबेस को पुनर्स्थापित करने की कोशिश कर रहा था। मेरे लिए इस समस्या को हल करने से my.conf में कुछ सेटिंग्स जुड़ गईं (जैसे ऊपर दिए गए प्रश्न) और इसके अतिरिक्त sql बैकअप फ़ाइल को बदलना:

चरण 1: my.conf में निम्न पंक्तियों को जोड़ें या संपादित करें:

innodb_page_size=32K
innodb_file_format=Barracuda
innodb_file_per_table=1

चरण 2 तालिका में ROW_FORMAT = डायनामिक जोड़ें तालिका के लिए sql बैकअप फ़ाइल में स्टेटमेंट बनाएं जो इस त्रुटि का कारण बन रहा है:

DROP TABLE IF EXISTS `problematic_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `problematic_table` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
  ...
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 ROW_FORMAT=DYNAMIC;

उपरोक्त महत्वपूर्ण परिवर्तन ROW_FORMAT = डायनामिक है; (यह orignal sql बैकअप फ़ाइल में शामिल नहीं था)

स्रोत जिसने मुझे इस समस्या को हल करने में मदद की: MariaDB और InnoDB MySQL रो आकार बहुत बड़ा है

Comments

चरण 1 में वर्णित लाइनों में कोई स्थान नहीं होना चाहिए। रेखा innodb_page_size=32Kने काम नहीं किया, क्योंकि इससे मेरे मामले में MariaDB 10.2 को पुनः आरंभ करने में त्रुटि हुई। इसके बजाय, मैंने innodb_strict_mode=0लाइन जोड़ दी , जैसा कि यहाँ

— Pathros

प्रतिक्रिया Pathros के लिए धन्यवाद, मैंने अपना उत्तर अपडेट किया और चरण 1 से रिक्त स्थान हटा दिए।

— मटियास

MySQL के लिए नोट <= 5.7.5: 32K innodb_page_size के लिए वैध विकल्प नहीं है। देखें: dev.mysql.com/doc/refman/5.6/en/…

— डब नज़र

इसके अलावा, आपको स्क्रेच के लिए अपने पूरे mysql सर्वर को फिर से बनाना होगा, क्योंकि बदलने के innodb_page_sizeलिए ibdata*मनोरंजन की आवश्यकता होती है , जो विनाशकारी ऑपरेशन है। अधिक जानकारी के लिए अपने syslog देखें

— मतिजा नालिस

Answer 9

अन्य उत्तर पूछे गए प्रश्न को संबोधित करते हैं। मैं अंतर्निहित कारण को संबोधित करूंगा: खराब स्कीमा डिजाइन।

स्तंभों पर किसी सरणी को विभाजित न करें। यहां आपके पास 3 * 10 कॉलम हैं जिन्हें एक नई तालिका (प्लस id, आदि) में 3 कॉलम की 10 पंक्तियों में बदलना चाहिए

आपकी Mainतालिका केवल होती

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
status  int(11) No       
admin_id    int(11) No 

आपकी अतिरिक्त तालिका ( Top) होगी

id  int(11) No          -- for joining to Main
seq TINYINT UNSIGNED    -- containing 1..10
img   varchar(255)    No       
title varchar(255)    No       
desc  text    No    
PRIMARY KEY(id, seq)    -- so you can easily find the 10 top_titles

प्रत्येक के लिए 10 (या कम? या अधिक?) पंक्तियाँ Topहोंगी id।

यह आपकी मूल समस्या को समाप्त करता है, और स्कीमा को साफ करता है। (यह "सामान्यीकरण" नहीं है, जैसा कि कुछ टिप्पणियों में किया गया था।)

क्या नहीं MyISAM करने के लिए स्विच; यह दूर जा रहा है।
चिंता मत करो ROW_FORMAT।

आपको JOINकई कॉलम के बजाय कई पंक्तियों को करने और संभालने के लिए अपना कोड बदलना होगा ।

Answer 10

मैं AWS RDS पर MySQL 5.6 का उपयोग कर रहा हूं। मैंने पैरामीटर समूह में निम्नलिखित अपडेट किया।

innodb_file_per_table=1
innodb_file_format = Barracuda

मुझे प्रभावी होने के लिए पैरामीटर समूह परिवर्तनों के लिए DB उदाहरण को रिबूट करना पड़ा।

साथ ही, ROW_FORMAT = COMPRESSED समर्थित नहीं था। मैंने नीचे के रूप में डायनामिक का उपयोग किया और यह ठीक काम किया।

ALTER TABLE nombre_tabla ENGINE=InnoDB ROW_FORMAT=DYNAMIC KEY_BLOCK_SIZE=8

Answer 11

एक InnoDB तालिका के लिए अधिकतम पंक्ति आकार, जो एक डेटाबेस पेज के भीतर स्थानीय रूप से संग्रहीत डेटा पर लागू होता है , 4KB, 8KB, 16KB और 32KB के लिए आधे पेज से थोड़ा कम है

16kb पृष्ठों (डिफ़ॉल्ट) के लिए, हम गणना कर सकते हैं:

Slightly less than half a page 8126 / Number of bytes to threshold for overflow 767 = 10.59 fields of 767 bytes maximum

असल में, आप एक पंक्ति को अधिकतम कर सकते हैं:

• 11 वरचर फ़ील्ड> 767 वर्ण (लैटिन 1 = 1 बाइट प्रति चार) या
• 11 चरचर क्षेत्र> 255 वर्ण (mysql पर utf-8 = प्रति चार्ट 3 बाइट्स)।

याद रखें, यह केवल एक अतिप्रवाह पृष्ठ पर अतिप्रवाह होगा यदि फ़ील्ड> 767 बाइट्स है। यदि 767 बाइट्स के बहुत सारे क्षेत्र हैं, तो यह बस्ट (अधिकतम रो_सेज़ से परे) होगा। अगर डेवलपर्स सावधान नहीं हैं, तो utf-8 के साथ बहुत संभव नहीं है, लेकिन लैटिन 1 के साथ सामान्य नहीं है।

इस स्थिति के लिए, मुझे लगता है कि आप संभवतः 32kb पर innodb_page_size को टक्कर दे सकते हैं।

my.cnf में:

innodb_page_size=32K

संदर्भ:

• https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html#row-size-limits
• https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
• https://mariadb.com/kb/en/library/innodb-compact-row-format/#overflow-pages-with-the-compact-row-format
• Innodb पृष्ठ आकार सेटिंग

Answer 12

मुझे भी इसी समस्या का सामना करना पड़ा। मैं निम्नलिखित sql निष्पादित करके समस्या का समाधान करता हूं:

ALTER ${table} ROW_FORMAT=COMPRESSED;

लेकिन, मुझे लगता है कि यू को रो स्टोरेज के बारे में पता होना चाहिए ।
स्तंभ दो प्रकार के होते हैं: परिवर्तनशील-लंबाई वाला स्तंभ (जैसे VARCHAR, VARBINARY, और BLOB और TEXT प्रकार) और निश्चित-लंबाई वाला स्तंभ । उन्हें विभिन्न प्रकार के पृष्ठों में संग्रहीत किया जाता है।

चर-लंबाई वाले कॉलम इस नियम के अपवाद हैं। BOB और VARCHAR जैसे स्तंभ जो B-Tree पृष्ठ पर फिट होने के लिए बहुत लंबे हैं, उन्हें अलग-अलग आवंटित डिस्क पृष्ठों पर संग्रहीत किया जाता है जिन्हें ओवरफ़्लो पृष्ठ कहा जाता है। हम ऐसे कॉलमों को ऑफ-पेज कॉलम कहते हैं। इन स्तंभों के मानों को अतिप्रवाह पृष्ठों की एकल-लिंक्ड सूची में संग्रहीत किया जाता है, और इस तरह के प्रत्येक स्तंभ की एक या एक से अधिक प्रवाह पृष्ठों की अपनी सूची होती है। कुछ मामलों में, लंबे स्तंभ मान का सभी या उपसर्ग B- ट्री में संग्रहित किया जाता है, जिससे भंडारण को बर्बाद करने से बचा जा सके और एक अलग पृष्ठ को पढ़ने की आवश्यकता को समाप्त किया जा सके।

और जब ROW_FORMAT की स्थापना का उद्देश्य है

जब एक तालिका ROW_FORMAT = DYNAMIC या ROW_FORMAT = COMPRESSED के साथ बनाई जाती है, तो InnoDB लॉन्ग वेरिएबल-लेंथ कॉलम वैल्यू (VARCHAR, VARBINARY, और BLOB और TEXT टाइप के लिए) पूरी तरह से ऑफ-पेज पर स्टोर हो सकती है, केवल एक 20- युक्त क्लस्टर इंडेक्स रिकॉर्ड के साथ। बाइट सूचक ओवरफ़्लो पृष्ठ पर।

डायनामिक और कम्प्यूटेड पंक्ति स्वरूपों के बारे में अधिक जानना चाहते हैं

Answer 13

यदि यह कई स्तंभों के साथ एक चयन पर होता है, तो इसका कारण यह हो सकता है कि mysql एक अस्थायी तालिका बना रहा है। यदि यह तालिका मेमोरी में फिट होने के लिए बहुत बड़ी है, तो यह डिस्क पर संग्रहीत करने के लिए अपने डिफ़ॉल्ट अस्थायी तालिका प्रारूप का उपयोग करेगा, जो कि इनोबीडी है। इस स्थिति में InnoDB आकार सीमा लागू होती है।

फिर आपके पास 4 विकल्प हैं:

1. किसी अन्य पोस्ट में बताई गई निर्दोष पंक्ति आकार सीमा को बदल दें, जिसके लिए सर्वर के पुनर्संरचनाकरण की आवश्यकता होती है।
2. कम कॉलम शामिल करने के लिए अपनी क्वेरी बदलें या अस्थायी तालिका बनाने के लिए इसे रोकने से बचें (द्वारा क्रम को हटाकर और खंड को सीमित करके)।
3. बदलने के लिए max_heap_table_size बड़ा है इसलिए परिणाम स्मृति में फिट बैठता है और डिस्क पर लिखे जाने की आवश्यकता नहीं है।

4. डिफ़ॉल्ट अस्थायी तालिका स्वरूप को MYISAM में बदलें, यही मैंने किया है। My.cnf में बदलें:

   internal_tmp_disk_storage_engine=MYISAM

Mysql को पुनरारंभ करें, क्वेरी काम करती है।

Answer 14

यहाँ कोई दिलचस्पी के लिए सरल टिप है:

Debian 9 से Debian 10 में 10.3.17-MariaDB के साथ अपग्रेड करने के बाद, मुझे जूमला डेटाबेस से कुछ त्रुटियां हैं:

[चेतावनी] InnoDB: fieldतालिका में फ़ील्ड नहीं जोड़ सकते database। tableक्योंकि इसे जोड़ने के बाद, पंक्ति का आकार 8742 है जो कि इंडेक्स लीफ पेज पर रिकॉर्ड के लिए अधिकतम अनुमत आकार (8126) से अधिक है।

बस के मामले में, मैंने innodb_default_row_format = डायनामिक को /etc/mysql/mariadb.conf.d/50-server.cnf में सेट किया (यह वैसे भी डिफ़ॉल्ट था)

थान, मैंने जूमला डेटाबेस में सभी तालिकाओं के लिए "ऑप्टिमाइज़ टेबल" चलाने के लिए phpmyadmin का उपयोग किया है। मुझे लगता है कि इस प्रक्रिया में phpmyadmin द्वारा किए गए तालिका मनोरंजन ने मदद की। यदि आप phpmyadmin स्थापित करने के लिए होता है तो यह करने के लिए बस कुछ ही क्लिक है।

Comments

यदि आप एक जूमला उपयोगकर्ता हैं, तो जूमला स्टैक एक्सचेंज में हमारे साथ आएं - हम हमेशा नए योगदानकर्ताओं का उपयोग कर सकते हैं।

— मिकमैकुसा