# 1071 - निर्दिष्ट कुंजी बहुत लंबी थी; अधिकतम कुंजी लंबाई 767 बाइट्स है

Question

जब मैंने निम्नलिखित कमांड निष्पादित की:

ALTER TABLE `mytable` ADD UNIQUE (
`column1` ,
`column2`
);

मुझे यह त्रुटि संदेश मिला:

#1071 - Specified key was too long; max key length is 767 bytes

कॉलम 1 और कॉलम 2 के बारे में जानकारी:

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

मुझे लगता है कि varchar(20)केवल 21 बाइट्स की varchar(500)आवश्यकता है, जबकि केवल 501 बाइट्स की आवश्यकता है। तो कुल बाइट्स 522 हैं, 767 से कम हैं। तो मुझे त्रुटि संदेश क्यों मिला?

#1071 - Specified key was too long; max key length is 767 bytes

Comments

क्योंकि इसकी 520 बाइट्स नहीं हैं, बल्कि 2080 बाइट्स हैं, जो अब तक 767 बाइट्स से अधिक हैं, तो आप कॉलम 1 वर्चर (20) और कॉलम 2 वर्चर (170) कर सकते हैं। यदि आप एक चरित्र / बाइट

— इक्विव

मुझे लगता है कि यहां आपकी गणना थोड़ी गलत है। mysql मान लंबाई दर्ज करने के लिए 1 या 2 अतिरिक्त बाइट्स का उपयोग करता है: 1 बाइट यदि कॉलम की अधिकतम लंबाई 255 बाइट्स या उससे कम है, 2 यदि यह 255 बाइट्स से अधिक है। utf8_general_ci एन्कोडिंग को प्रति वर्ण 3 बाइट्स की आवश्यकता होती है, इसलिए varchar (20) 61 बाइट्स का उपयोग करता है, varchar (500) कुल 1563 बाइट्स में 1502 बाइट्स का उपयोग करता है

— अरोकोविले 10

mysql> जानकारी_schema.character_sets से '' latin1 ',' utf8 ',' utf8mb4 'में से maxlen, character_set_name चुनें; मैक्सलेन | character_set_name ------ | ------------------- १ | लैटिन 1 ------ | ------------------- ३ | utf8 ------ | ------------------- ४ | utf8mb4

— 13-13 पर अभाव

'यदि आप एक चरित्र / बाइट इक्विव चाहते हैं, तो लैटिन 1 का उपयोग करें' कृपया ऐसा न करें । लैटिन 1 वास्तव में, वास्तव में बेकार है। तुम्हें इसका अफसोस होगा।

— स्टिजेन डे विट

देखें stackoverflow.com/a/52778785/2137210 समाधान के लिए

— प्रतीक

Answer 1

767 बाइट्स MySQL संस्करण 5.6 (और पूर्व संस्करणों) में InnoDB तालिकाओं के लिए उपसर्ग सीमा है । यह MyISAM तालिकाओं के लिए 1,000 बाइट्स लंबा है। MySQL संस्करण 5.7 और इसके बाद के संस्करण में इस सीमा को बढ़ाकर 3072 बाइट्स कर दिया गया है।

आपको यह भी जानना होगा कि यदि आप एक बड़े char या varchar फ़ील्ड पर एक इंडेक्स सेट करते हैं, जो कि utf8mb4 एन्कोडेड है, तो आपको 191 के परिणामस्वरूप 767 बाइट्स (या 3072 बाइट्स) की अधिकतम इंडेक्स उपसर्ग लंबाई को विभाजित करना होगा। यह इसलिए है क्योंकि एक utf8mb4 वर्ण की अधिकतम लंबाई चार बाइट्स है। एक utf8 वर्ण के लिए यह तीन बाइट्स होगा जिसके परिणामस्वरूप अधिकतम सूचकांक 254 की अधिकतम उपसर्ग लंबाई होगी।

आपके पास एक विकल्प यह है कि आप अपने VARCHAR क्षेत्रों पर कम सीमा रखें।

एक अन्य विकल्प ( इस मुद्दे की प्रतिक्रिया के अनुसार ) संपूर्ण राशि के बजाय कॉलम का सबसेट प्राप्त करना है, अर्थात:

ALTER TABLE `mytable` ADD UNIQUE ( column1(15), column2(200) );

जैसा कि आपको आवेदन करने के लिए कुंजी प्राप्त करने की आवश्यकता है, लेकिन मुझे आश्चर्य है कि क्या इस इकाई के बारे में अपने डेटा मॉडल की समीक्षा करने के लिए यह देखने लायक होगा कि क्या इसमें सुधार है जो आपको MySQL सीमा को मारने के बिना इच्छित व्यावसायिक नियमों को लागू करने की अनुमति देगा।

Comments

संपूर्ण राशि के बजाय कॉलम का सबसेट निर्दिष्ट करके लागू करने के लिए। एक अच्छा उपाय।

— स्टीवन

यह स्पष्ट नहीं करता है कि लंबाई सीमा से नीचे के क्षेत्र अच्छी तरह से लंबाई की सीमा को पार क्यों कर रहे हैं ...

— सेरिन

मैंने जानकारी में संपादन की कोशिश की है @Cerin ऊपर गायब है, जिसे स्पष्ट रूप से दूसरों द्वारा भी गायब माना जाता है, लेकिन यह एक टिप्पणी के रूप में अधिक उपयुक्त होने के रूप में खारिज कर दिया जाता है। जो लोग समझने की कोशिश कर रहे हैं उनके लिए 500 + 20> 767 जुलिएन के जवाब पर स्टीफन एंड्रुलिस की टिप्पणी क्यों देखें।

— रात्रि

यह एक समस्या हो सकती है। उदाहरण के लिए: मेरे पास फ़ील्ड नाम (255) है और इस क्षेत्र में नाम (191) में अद्वितीय जोड़ें क्योंकि मैं utf8mb4 का उपयोग कर रहा हूं। यदि मेरे पास मेरा उपयोगकर्ता 'IJUE3ump5fiUuCi16jSofYS234MLschW4wsIktKiBrTPOTKBK6Vteh5pNuz1tKn ... ... aO500mlJs' के साथ अपना नाम जोड़ता है और दूसरा उपयोगकर्ता इस नाम के साथ अपना नाम 'IJUE3ump5UUC5f5UUf5UUf5UUC5UUUUCUUCUU'Cf5CUU.Cf5CUU.Cf5UUsffxfxfxfxfxf5xfxfxf5xnxfxf5xf5xfxf5xnxfxf5xf5xfxf5xfxf5xf5xnxf5x इसवीकारी है।' यह डुप्लिकेट प्रविष्टि पर अटक नहीं होना चाहिए।

— वी। जूल

सूचकांक सीमा 767 बाइट्स है , वर्ण नहीं। और जब से मैसकल के utf8mb4चरित्र सेट (जिसे बाकी दुनिया utf8 कहते हैं) की जरूरत है (कम से कम) 4 बाइट्स प्रति वर्ण आप केवल अनुक्रमण कर सकते हैं VARCHAR(191)। मैसकल का utf8कैरेक्टर सेट (जिसे बाकी दुनिया तोड़ती है) को प्रति कैरेक्टर 3 बाइट्स की जरूरत होती है, ताकि अगर आप उसका इस्तेमाल कर रहे हैं (जो आपको नहीं करना चाहिए ), तो आप इसे इंडेक्स कर सकते हैंVARCHAR(255)

— Stijn de Witt

Answer 2

यदि किसी के पास INNODB / Utf-8 के साथ कोई समस्या है, तो किसी फ़ील्ड UNIQUEपर एक इंडेक्स डालने की कोशिश कर रहा है VARCHAR(256), उसे स्विच करें VARCHAR(255)। ऐसा लगता है कि 255 सीमा है।

Comments

अनुमत वर्णों की संख्या आपके चरित्र सेट पर निर्भर करती है। UTF8 प्रति चरित्र में 3 बाइट्स तक उपयोग कर सकता है, utf8mb4 4 बाइट्स तक, और लैटिन 1 केवल 1 बाइट। इस प्रकार utf8 के लिए आपकी कुंजी लंबाई 255 वर्णों तक सीमित है, क्योंकि 3*255 = 765 < 767।

— स्टीफन एंडरुलिस

इससे मुझे बहुत निराशा हुई - धन्यवाद। यह स्वीकार किए जाने वाला उत्तर IMO होना चाहिए, यह विचार करते हुए कि उपयोगकर्ता 767b सीमा हिट करने का दावा करके InnoDB का उपयोग कर रहा है।

— कार्वर

एएस स्टीफन एंडरुलिस ने कहा, यह चारसेट पर निर्भर करता है। यदि आप UTF8 का उपयोग करते हैं जो 3 बाइट्स का उपयोग करता है: 255x3 = 765 जो 767 सीमा से कम है, जबकि 256x3 = 768 जो अधिक है। लेकिन अगर आप UTF8mb4 का उपयोग इसके 255 * 4 = 1020 करते हैं, तो इसका कोई

— वास्तविक

यह उत्तर सही है। हालांकि अगर 255 वास्तव में आपके लिए काम कर रहा है, तो इसका मतलब है कि आप मैसकल का उपयोग कर रहे हैं utf8, जो दुर्भाग्य से टूट गया है। यह केवल मूल बहुभाषी विमान में वर्णों को एनकोड कर सकता है। आपको इसके बाहर गिरने वाले पात्रों के साथ मुद्दे मिलेंगे। उदाहरण के लिए उन इमोजी पात्रों को जो वे सोचते हैं कि मैं इससे बाहर गिर रहा हूं। इसलिए स्विच करने के बजाय VARCHAR(255), एन्कोडिंग पर स्विच करें VARCHAR(191) और स्विच करें utf8mb4(जो वास्तव में केवल utf8 है, लेकिन MySql को वापस रखने के लिए। कॉम्पिटिटर)।

— स्टिजन डे विट

मेरी बहुरंगी अनूठी बाधा के लिए सहायक नहीं। यह ओपी के बहुरंगी अद्वितीय अवरोध के लिए भी काम नहीं करेगा। (यह 825 बाइट्स का कुल आकार देगा)

— बर्ट

Answer 3

जब आप सीमा को मारते हैं। निम्नलिखित सेट करें।

• InnoDB utf8 VARCHAR(255)
• InnoDB utf8mb4 VARCHAR(191)

Comments

यह सबसे अच्छा जवाब है। सरल, सीधे बिंदु पर और utf8mb4सीमा भी शामिल है (जो नए डेटाबेस के लिए सबसे अधिक इस्तेमाल किया जाने वाला एन्कोडिंग है, क्योंकि यह इमोजीस / आदि को स्वीकार करता है)।

— क्लाउडियो हॉलैंडा

क्योंकि 767/4 ~ = 191, और 767/3 ~ = 255

— एकाउंटेंट एन

इसे कहां और कैसे सेट करें?

— दिनेश सनी

हां, बयान ENGINE=InnoDB DEFAULT CHARSET=utf8के अंत में निर्दिष्ट करना CREATE TABLEमेरे पास एक VARCHAR(255)प्राथमिक कुंजी है। धन्यवाद।

— xonya

किसी ने उसे 191 :) की सीमा पार करने के लिए +1 दिया

— cagcak

Answer 4

MySQL स्ट्रिंग में प्रति वर्ण बाइट्स की संख्या के लिए सबसे खराब स्थिति मानता है। MySQL 'utf8' एन्कोडिंग के लिए, यह प्रति वर्ण 3 बाइट्स है क्योंकि एन्कोडिंग वर्णों से परे की अनुमति नहीं देता है U+FFFF। MySQL 'utf8mb4' एन्कोडिंग के लिए, यह प्रति वर्ण 4 बाइट्स है, क्योंकि यही MySQL वास्तविक UTF-8 कहलाता है।

इसलिए मान लें कि आप 'utf8' का उपयोग कर रहे हैं, तो आपका पहला कॉलम इंडेक्स के 60 बाइट लेगा, और आपका दूसरा 1500।

Comments

- जो संभवतः इसका मतलब है कि utf8mb4 का उपयोग करते समय, मुझे उन्हें (सबसे अधिक) 191 पर 191 * 4 = 764 <767 के रूप में सेट करने की आवश्यकता है।

— इसहाक

@ आइसाक हां, बिल्कुल,

— मॉर्गनवेल

मुझे लगता है कि यह सही उत्तर हो सकता है, लेकिन क्या आप इस बात पर विस्तृत चर्चा कर सकते हैं कि ऐसे मुद्दे को सही करने के लिए किसी को क्या करने की आवश्यकता होगी? कम से कम मेरे जैसे MySQL noobs के लिए?

— एडम ग्रांट

इस सूचकांक सीमा के आसपास जाने का कोई एक तरीका नहीं है। यहाँ सवाल अद्वितीय बाधाओं के बारे में है; उन लोगों के लिए, आपके पास असीमित लंबाई के पाठ का एक स्तंभ हो सकता है, और दूसरा जहां आप उस पाठ का हैश (जैसे एमडी 5) स्टोर करते हैं, और अपने अद्वितीय अवरोध के लिए हैश कॉलम का उपयोग करते हैं। आपको यह सुनिश्चित करना होगा कि पाठ को बदलने के दौरान आपका कार्यक्रम हैश-अप-टू-डेट रहता है, लेकिन बिना किसी परेशानी के इसे संभालने के विभिन्न तरीके हैं। बहुत स्पष्ट रूप से, MySQL को ऐसी चीज़ को स्वयं लागू करना चाहिए ताकि आपको ऐसा न करना पड़े; मुझे आश्चर्य नहीं होगा अगर मारियाडीबी में कुछ ऐसा बिल्ट-इन है।

— मॉर्गनवहल

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

— स्टिजन डी विट

Answer 5

अपनी क्वेरी से पहले इस प्रश्न को चलाएं:

SET @@global.innodb_large_prefix = 1;

इससे सीमा में वृद्धि होगी 3072 bytes।

Comments

क्या वैश्विक स्तर पर innodb_large_prefix में बदलने के लिए कोई नकारात्मक पहलू है? और क्या वह DB "वैश्विक" या सभी DBs पूरी तरह वैश्विक है?

— 22

केवल गैर-मानक पंक्ति स्वरूपों का उपयोग करते समय लागू होता है। Dev.mysql.com/doc/refman/5.5/en/… देखें । विशेष रूप से, 'डायनामिक और कम्प्रेस्ड रो फॉर्मेट्स का उपयोग करने वाली इनोबीडी टेबलों के लिए 767 बाइट्स (3072 बाइट्स तक) की अनुक्रमणिका कुंजी उपसर्गों की अनुमति देने के लिए इस विकल्प को सक्षम करें।' डिफ़ॉल्ट पंक्ति प्रारूप अप्रभावित है।

— क्रिस लीयर

यह मेरे लिए अच्छी तरह से काम करता है - अधिक विवरण और एक गाइड यहां पाया जा सकता है: यांत्रिकी.फ्लाइट

— com

क्या हमें इसके बाद mysql सर्वर को पुनरारंभ करने की आवश्यकता है?

— सिंपल जीयू

इस उत्तर से महत्वपूर्ण गुम विवरण। innodb_file_formatहोना चाहिए BARRACUDAऔर टेबल स्तर पर आपको उपयोग करना है ROW_FORMAT=DYNAMICया ROW_FORMAT=COMPRESSED। ऊपर गाइड के साथ @ cwd की टिप्पणी देखें।

— q0rban

Answer 6

लारवेल फ्रेमवर्क के लिए समाधान

लारवेल 5.4 के अनुसार । * प्रलेखन ; आपको फ़ाइल की bootविधि के अंदर डिफ़ॉल्ट स्ट्रिंग की लंबाई निर्धारित करनी होगी app/Providers/AppServiceProvider.php:

use Illuminate\Support\Facades\Schema;

public function boot() 
{
    Schema::defaultStringLength(191); 
}

इस सुधार का स्पष्टीकरण, लारवेल 5.4 द्वारा दिया गया । * प्रलेखन :

लारवेल utf8mb4डिफ़ॉल्ट रूप से सेट किए गए वर्ण का उपयोग करता है , जिसमें डेटाबेस में "इमोजीस" के भंडारण के लिए समर्थन शामिल है। यदि आप 5.7.7 रिलीज़ से पुराने MySQL का संस्करण चला रहे हैं या 10.2.2 रिलीज़ से अधिक पुराना MariaDB है, तो आपको उनके लिए अनुक्रमणिका बनाने के लिए MySQL के लिए माइग्रेशन द्वारा उत्पन्न डिफ़ॉल्ट स्ट्रिंग लंबाई को मैन्युअल रूप से कॉन्फ़िगर करने की आवश्यकता हो सकती है। आप Schema::defaultStringLengthअपने भीतर विधि को कॉल करके इसे कॉन्फ़िगर कर सकते हैं AppServiceProvider।

वैकल्पिक रूप से, आप innodb_large_prefixअपने डेटाबेस के लिए विकल्प को सक्षम कर सकते हैं । इस विकल्प को ठीक से सक्षम करने के निर्देशों के लिए अपने डेटाबेस के प्रलेखन का संदर्भ लें।

Comments

@BojanPetkovic अच्छी तरह से मैं सिर्फ एक लारवेल मुद्दे से आया था, और इस जवाब ने वास्तव में मेरी समस्या हल कर दी।

— mkmnstr

यह उत्तर बहुत अच्छा है। लेकिन क्या कोई जानता है, कि वास्तव में यह क्यों काम करता है?

— UeliDeSchwert

@ बॉबी लारवेल डॉक्यूमेंटेशन शीर्षक "इंडेक्स लेंथ्स

— अली शौकत

@ बॉबी मैंने जवाब अपडेट कर दिया है। मैंने इस सुधार के लिए लार्वा प्रलेखन द्वारा दिए गए स्पष्टीकरण को जोड़ा है।

— अली शौकत

Answer 7

आप किस वर्ण एन्कोडिंग का उपयोग कर रहे हैं? कुछ वर्ण सेट (जैसे UTF-16, et cetera) प्रति वर्ण एक से अधिक बाइट का उपयोग करते हैं।

Comments

यदि यह UTF8 है, तो एक चरित्र अधिकतम 4 बाइट्स का उपयोग कर सकता है, ताकि 20 वर्ण स्तंभ 20 * 4 + 1बाइट्स हो, और 500 वर्ण स्तंभ 500 * 4 + 2बाइट्स

— थानातोस

जो इसके लायक है, उसके लिए मेरे पास बस यही समस्या थी और utf8_general_ci से utf8_unicode_ci पर स्विच करने से मेरे लिए समस्या हल हो गई। मैं नहीं जानता कि यद्यपि क्यों :(

— एन्ड्रेस सर्ज जूल

VARCHAR(256)एक UNIQUEइंडेक्स वाले कॉलम के लिए , बदलते कॉलेशन का मेरे लिए कोई प्रभाव नहीं था, जैसे कि @Andresch के लिए। हालाँकि, लंबाई को 256 से घटाकर 255 करने से इसका समाधान हो गया। मुझे समझ में नहीं आता है, क्योंकि 767 / अधिकतम 4 बाइट्स प्रति वर्ण अधिकतम 191 होगा?

— अर्जन

255*3 = 765; 256*3 = 768। ऐसा लगता है कि आपका सर्वर प्रति चरित्र 3 बाइट्स मान रहा था, @ अर्जन

— एम्बर

@Greg: आप सही हैं, लेकिन यह विस्तृत होना चाहिए: UTF-8 स्वयं प्रति कोड बिंदु पर 1-4 बाइट्स का उपयोग करता है। MySQL के "कैरेक्टर सेट्स" (वास्तव में एन्कोडिंग) में "utf8" नामक एक कैरेक्टर सेट होता है , जो UTF-8 में से कुछ को एनकोड करने में सक्षम होता है , और प्रति कोड पॉइंट पर 1-3 बाइट्स का उपयोग करता है, और बीएमपी के बाहर कोड पॉइंट्स को एन्कोड करने में असमर्थ होता है। इसमें "utf8mb4" नामक एक अन्य वर्ण सेट भी शामिल है, जो कोड बिंदु प्रति 1-4 बाइट्स का उपयोग करता है, और सभी यूनिकोड कोड बिंदुओं को एन्कोड करने में सक्षम है। (utf8mb4 UTF-8 है, utf8 UTF-8 का एक अजीब संस्करण है।)

— थानाटोस

Answer 8

मुझे लगता है कि varchar (20) को केवल 21 बाइट्स की आवश्यकता होती है जबकि varchar (500) को केवल 501 बाइट्स की आवश्यकता होती है। तो कुल बाइट्स 522 हैं, 767 से कम हैं। तो मुझे त्रुटि संदेश क्यों मिला?

स्ट्रिंग को संग्रहीत करने के लिए UTF8 को प्रति वर्ण में 3 बाइट्स की आवश्यकता होती है , इसलिए आपके मामले में 20 + 500 वर्ण = 20 * 3 + 500 * 3 = 1560 बाइट्स जो अनुमत 767 बाइट्स से अधिक है ।

UTF8 के लिए सीमा 767/3 = 255 वर्ण है , UTF8mb4 के लिए जो प्रति वर्ण 4 बाइट्स का उपयोग करता है यह 767/4 = 191 वर्ण है।

---

इस समस्या के दो समाधान हैं यदि आपको सीमा से अधिक लंबे स्तंभ का उपयोग करने की आवश्यकता है:

1. "सस्ता" एन्कोडिंग का उपयोग करें (एक जिसे प्रति चरित्र कम बाइट्स की आवश्यकता होती है)
   मेरे मामले में, मुझे लेख के एसईओ स्ट्रिंग वाले कॉलम पर अद्वितीय सूचकांक जोड़ने की आवश्यकता थी, क्योंकि मैं [A-z0-9\-]एसईओ के लिए केवल वर्णों latin1_general_ciका उपयोग करता हूं, मैंने उपयोग किया था जो केवल एक बाइट प्रति वर्ण का उपयोग करता है और इसलिए कॉलम में 767 बाइट्स की लंबाई हो सकती है।
2. अपने कॉलम से हैश बनाएँ और उस पर केवल अनन्य सूचकांक का उपयोग करें
   । मेरे लिए दूसरा विकल्प एक और कॉलम बनाना था जो SEO के हैश को स्टोर करेगा, यह कॉलम UNIQUEसुनिश्चित करने के लिए महत्वपूर्ण होगा कि SEO मान अद्वितीय हैं। मैं KEYमूल एसईओ कॉलम में इंडेक्स को जोड़ने के लिए भी तेजी से देखूंगा।

Comments

यह चाल चली। मेरे पास varchar (256) है और मुझे इसे varchar (250) में बदलना पड़ा।

— मैमर

Answer 9

आपको त्रुटि संदेश क्यों मिलता है, इस बारे में जवाब पहले से ही कई उपयोगकर्ताओं द्वारा यहां दिया गया था। मेरा उत्तर इस बारे में है कि इसे कैसे ठीक किया जाए और इसका उपयोग किया जाए।

इस लिंक से देखें ।

1. MySQL क्लाइंट (या MariaDB क्लाइंट) खोलें। यह एक कमांड लाइन टूल है।
2. यह आपका पासवर्ड पूछेगा, अपना सही पासवर्ड दर्ज करें।
3. इस आदेश का उपयोग करके अपने डेटाबेस का चयन करें use my_database_name;

डेटाबेस बदल गया

4. set global innodb_large_prefix=on;

क्वेरी ठीक है, 0 पंक्तियाँ प्रभावित (0.00 सेकंड)

5. set global innodb_file_format=Barracuda;

क्वेरी ठीक, 0 पंक्तियाँ प्रभावित (0.02 सेकंड)

6. अपने डेटाबेस पर जाएं phpMyAdmin या ऐसा कुछ आसान प्रबंधन के लिए। > डेटाबेस चुनें> तालिका संरचना देखें > ऑपरेशन टैब पर जाएं । > ROW_FORMAT को डायनामिक में बदलें और परिवर्तन सहेजें।
7. तालिका की संरचना टैब पर जाएं> अद्वितीय बटन पर क्लिक करें।
8. किया हुआ। अब इसमें कोई त्रुटि नहीं होनी चाहिए।

इस फिक्स की समस्या यह है कि यदि आप किसी अन्य सर्वर (उदाहरण के लिए लोकलहोस्ट से वास्तविक होस्ट) के लिए db निर्यात करते हैं और आप उस सर्वर में MySQL कमांड लाइन का उपयोग नहीं कर सकते हैं। आप इसे वहां काम नहीं कर सकते।

Comments

यदि आप क्वेरी के बाद दर्ज करने के बाद भी त्रुटि कर रहे हैं, तो "phpmyadmin"> अपनी पसंद के लिए "टकराव" सेट करने की कोशिश करें (मेरे लिए मैं "utf8_general_ci" का उपयोग करता हूं)> आवेदन पर क्लिक करें (भले ही इसकी पहले से ही ff8 हो)

— एंथनी काल

मैं एक उपकरण का उपयोग नहीं कर रहा हूं जो आपके निर्देशों के साथ काम करता है, लेकिन मैं अभी भी इसे वोट कर रहा हूं ताकि वास्तव में समस्या को ठीक करने वाले लोगों की मदद करने की कोशिश की जा सके । समस्या का कारण क्या है, इसके अंतहीन स्पष्टीकरण हैं, लेकिन वास्तव में इसे कैसे हल किया जाए, इस पर बहुत कम।

— टेकिन

Answer 10

Specified key was too long; max key length is 767 bytes

आपको वह संदेश मिल गया है क्योंकि 1 बाइट 1 वर्ण के बराबर है यदि आप latin-1वर्ण सेट का उपयोग करते हैं । यदि आप उपयोग करते हैं utf8, तो आपके मुख्य कॉलम को परिभाषित करते समय प्रत्येक वर्ण को 3 बाइट माना जाएगा। यदि आप उपयोग करते हैं utf8mb4, तो आपके मुख्य कॉलम को परिभाषित करते समय प्रत्येक वर्ण को 4 बाइट्स माना जाएगा। इस प्रकार, आपको अपने मुख्य फ़ील्ड की वर्ण सीमा 1, 3, या 4 (मेरे उदाहरण में) को बाइट्स की संख्या निर्धारित करने के लिए निर्धारित करने की आवश्यकता है, जो कुंजी फ़ील्ड अनुमति देने की कोशिश कर रही है। यदि आप uft8mb4 का उपयोग कर रहे हैं, तो आप केवल 191 वर्णों को एक देशी, InnoDB, प्राथमिक कुंजी फ़ील्ड के लिए परिभाषित कर सकते हैं। बस 767 बाइट्स भंग न करें।

Answer 11

आप लंबे कॉलम के md5 का एक कॉलम जोड़ सकते हैं

Comments

ध्यान दें कि यह आपको इन स्तंभों पर श्रेणी स्कैन करने की अनुमति नहीं देगा। VARCHARs पर उपसर्ग की लंबाई आपको इस विशेषता को बनाए रखने की अनुमति देगी, जबकि संभवतः सूचकांक में स्पुरियस मैच का कारण बनता है (और उन्हें खत्म करने के लिए स्कैनिंग और पंक्ति लुकअप) (स्वीकृत उत्तर देखें)। (यह अनिवार्य रूप से एक मैन्युअल रूप से लागू किया गया हैश इंडेक्स है, जो दुख की बात है कि मैसिन इनोबीडी तालिकाओं के साथ समर्थन नहीं करता है।)

— थानाटोस

मैं उपसर्ग सूचकांकों का उपयोग नहीं कर सकता क्योंकि मुझे परीक्षण उद्देश्यों के लिए H2 के साथ संगतता बनाए रखने की आवश्यकता थी, और एक हैश कॉलम का उपयोग करना अच्छी तरह से काम करता है। मैं दुर्भावनापूर्ण उपयोगकर्ताओं को टक्कर बनाने से रोकने के लिए MD5 के बजाय SHA1 जैसे टकराव प्रतिरोधी फ़ंक्शन का उपयोग करने की दृढ़ता से सलाह दूंगा। यदि आपकी कोई क्वेरी केवल हैश मान की जाँच करती है, और पूर्ण स्तंभ मान की नहीं, तो डेटा को लीक करने के लिए एक इंडेक्स टक्कर का फायदा उठाया जा सकता है।

— लिटिल माइक

Answer 12

बदलें utf8mb4के साथ utf8अपने आयात फ़ाइल में।

Comments

वास्तव में ऐसा क्यों करना चाहिए? इसके अतिरिक्त, अगर यह किसी भी डाउनसाइड्स (जो मुझे लगता है) है, तो आपको इसका उल्लेख करना चाहिए

— निको हासे

Answer 13

जब हमने utf8mb4 का उपयोग करके एक VARCHAR (255) क्षेत्र में एक UNIQUE सूचकांक जोड़ने की कोशिश करते समय इस मुद्दे का सामना किया। जबकि समस्या यहाँ पहले से ही रेखांकित है, मैं कुछ व्यावहारिक सलाह जोड़ना चाहता था कि हम इसे कैसे सुलझाते हैं और इसे हल करते हैं।

Utf8mb4 का उपयोग करते समय, वर्ण 4 बाइट्स के रूप में गिने जाते हैं, जबकि utf8 के तहत, वे 3 बाइट्स के रूप में हो सकते हैं। InnoDB डेटाबेस की एक सीमा है कि अनुक्रमित में केवल 767 बाइट्स हो सकते हैं। इसलिए utf8 का उपयोग करते समय, आप 255 वर्ण (767/3 = 255) संग्रहीत कर सकते हैं, लेकिन utf8mb4 का उपयोग करके, आप केवल 191 वर्ण (767/4 = 191) संग्रहीत कर सकते हैं।

आप VARCHAR(255)utf8mb4 का उपयोग करके फ़ील्ड के लिए नियमित अनुक्रमणिका जोड़ने में पूरी तरह से सक्षम हैं , लेकिन क्या होता है कि अनुक्रमणिका का आकार स्वचालित रूप से 191 वर्णों पर काट दिया जाता है - जैसे unique_keyयहाँ:

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

इसलिए, MySQL नियमित अनुक्रमित के लिए स्वचालित रूप से अनुक्रमणिका को छोटा क्यों करता है, लेकिन अद्वितीय अनुक्रमित के लिए यह करने की कोशिश करते समय एक स्पष्ट त्रुटि फेंक देता है? खैर, MySQL के लिए यह पता लगाने में सक्षम होने के लिए कि मूल्य डाला जा रहा है या अपडेट पहले से मौजूद है, इसे वास्तव में पूरे मूल्य को इंडेक्स करने की आवश्यकता है और न केवल इसका हिस्सा।

दिन के अंत में, यदि आप एक क्षेत्र पर एक अद्वितीय सूचकांक रखना चाहते हैं, तो क्षेत्र की संपूर्ण सामग्री को सूचकांक में फिट होना चाहिए। Utf8mb4 के लिए, इसका अर्थ है कि आपके VARCHAR क्षेत्र की लंबाई को 191 वर्ण या उससे कम करना। यदि आपको उस तालिका या फ़ील्ड के लिए utf8mb4 की आवश्यकता नहीं है, तो आप इसे utf8 पर वापस छोड़ सकते हैं और अपने 255 मिलियन फ़ील्ड रख सकते हैं।

Answer 14

यहाँ मेरा मूल उत्तर है:

मैं सिर्फ डेटाबेस को छोड़ देता हूं और इस तरह से पुन: बनाता हूं, और त्रुटि समाप्त हो गई है:

drop database if exists rhodes; create database rhodes default CHARACTER set utf8 default COLLATE utf8_general_ci;

हालाँकि, यह सभी मामलों के लिए काम नहीं करता है।

यह वास्तव में वर्ण सेट utf8(या utf8mb4) के साथ VARCHAR स्तंभों पर अनुक्रमणिका का उपयोग करने की समस्या है , जिसमें VARCHAR स्तंभ हैं जिनके वर्णों की एक निश्चित लंबाई से अधिक है। के मामले में utf8mb4, वह निश्चित लंबाई 191 है।

अधिक जानकारी के लिए कृपया इस लेख में लॉन्ग इंडेक्स सेक्शन का संदर्भ लें। MySQL डेटाबेस में लॉन्ग इंडेक्स का उपयोग कैसे करें: http://hanoian.com/content/index.php/24-automate-the-converting-a-mysql-database- चरित्र सेट करने के लिए utf8mb4

Comments

Openmeetings सेटअप की समस्या को हल किया (BTW आपने मेरी रात बचाई :-)

— लूडो

Answer 15

5 वर्कअराउंड:

सीमा 5.7.7 (मारियाडीबी 10.2.2?) में उठाया गया था। और इसे 5.6 (10.1) में कुछ काम के साथ बढ़ाया जा सकता है।

यदि आप CHARACTER SET utf8mb4 का उपयोग करने की कोशिश करने के कारण सीमा मार रहे हैं। फिर त्रुटि से बचने के लिए निम्न में से एक करें (प्रत्येक में एक दोष है):

⚈  Upgrade to 5.7.7 for 3072 byte limit -- your cloud may not provide this;
⚈  Change 255 to 191 on the VARCHAR -- you lose any values longer than 191 characters (unlikely?);
⚈  ALTER .. CONVERT TO utf8 -- you lose Emoji and some of Chinese;
⚈  Use a "prefix" index -- you lose some of the performance benefits.
⚈  Or... Stay with older version but perform 4 steps to raise the limit to 3072 bytes:

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_large_prefix=1;
logout & login (to get the global values);
ALTER TABLE tbl ROW_FORMAT=DYNAMIC;  -- (or COMPRESSED)

- http://mysql.rjweb.org/doc.php/limits#767_limit_in_innodb_indexes

Answer 16

मैंने इस मुद्दे को इसके साथ तय किया:

varchar(200) 

के साथ बदल दिया

varchar(191)

वे सभी चरचर जिनमें 200 से अधिक हैं, उन्हें 191 से बदल देते हैं या उन्हें पाठ सेट करते हैं।

Comments

मेरे लिए भी यही काम किया। मेरे पास एक varchar (250) था, लेकिन डेटा कभी भी इतना लंबा नहीं था। इसे परिवर्तन (100) में बदल दिया। विचार के लिए धन्यवाद :)

— अरुण बासिल लाल

Answer 17

मैंने इस विषय पर कुछ खोज की और अंत में कुछ कस्टम परिवर्तन हुए

MySQL वर्कबेंच के लिए 6.3.7 वर्जन ग्राफिकल इंटर फेज उपलब्ध है

1. कार्यक्षेत्र प्रारंभ करें और कनेक्शन का चयन करें।
2. प्रबंधन या इंस्टेंस पर जाएं और विकल्प फ़ाइल का चयन करें।
3. यदि कार्यक्षेत्र आपको कॉन्फ़िगरेशन फ़ाइल पढ़ने की अनुमति देता है और फिर दो बार ओके दबाकर अनुमति दें।
4. केंद्र स्थान पर व्यवस्थापक विकल्प फ़ाइल विंडो आती है।
5. InnoDB टैब पर जाएं और अगर जनरल सेक्शन में इसकी जांच नहीं हुई है तो innodb_large_prefix की जांच करें।
6. डायनामिक को innodb_default_row_format विकल्प मान सेट करें।

6.3.7 से नीचे के संस्करणों के लिए सीधे विकल्प उपलब्ध नहीं हैं, इसलिए कमांड प्रॉम्प्ट के साथ जाने की आवश्यकता है

1. प्रशासक के रूप में सीएमडी शुरू करें।
2. निदेशक के पास जाएं जहां mysql सर्वर "C: \ Program Files \ MySQL \ MySQL Server 5.7 \ bin" पर अधिकांश मामलों को स्थापित करता है, इसलिए कमांड "cd \" "cd प्रोग्राम फ़ाइलें \ MySQL \ MySQL सर्वर 5.7 \ bin" है।
3. अब रन कमांड mysql -u userName -p databasecheema अब यह संबंधित उपयोगकर्ता का पासवर्ड मांगता है। पासवर्ड प्रदान करें और mysql प्रॉम्प्ट में दर्ज करें।
4. हमें कुछ वैश्विक सेटिंग्स सेट करनी हैं नीचे दिए गए आदेशों को एक सेट करके एक वैश्विक innodb_large_prefix = चालू करें; वैश्विक innodb_file_format = बाराकुडा सेट करें; वैश्विक innodb_file_per_table = true सेट करें;
5. अब अंत में हमें अपने COMPACT को डिफ़ॉल्ट रूप से आवश्यक तालिका के ROW_FORMAT को बदलना होगा और हमें इसे डायनामिक पर सेट करना होगा।
6. निम्न आदेश परिवर्तन तालिका का उपयोग करें table_name ROW_FORMAT = डायनामिक;
7. किया हुआ

Comments

मुझे यह नहीं मिला: 6. डायनामिक को innodb_default_row_format विकल्प मान सेट करें।

— एड्रियन सीड अल्मागुएर

यदि मैं set global innodb_default_row_format = DYNAMIC;इस संदेश का उपयोग करता हूं: ERROR 1193 (HY000): अज्ञात सिस्टम वैरिएबल 'innodb_default_row_format'

— एड्रियन Cid

कैसे आप कार्यक्षेत्र से cmd के लिए त्रुटि मिली? मैंने इसे कार्यक्षेत्र से लिया था, इसका विकल्प सीधे है।

— अभिषेक

मैं सीएमडी से करता हूं क्योंकि मुझे कार्यक्षेत्र में विकल्प नहीं दिखता है

— एड्रियन सीआईडी ​​अल्मागुएर

मैं देख रहा हूँ कि इस समस्या को v5.7.9 में पेश किया गया था और मेरे पास v5.6.33 संस्करण है, धन्यवाद

— एड्रियन सिड

Answer 18

लार्वा 5.7 से 6.0 के लिए

पीछा करने के लिए कदम

1. के पास जाओ App\Providers\AppServiceProvider.php।
2. इसे use Illuminate\Support\Facades\Schema;शीर्ष में प्रदाता में जोड़ें ।
3. बूट फ़ंक्शन के अंदर इसे जोड़ें Schema::defaultStringLength(191);

वह सब, आनंद लें।

Comments

लारवेल 5.8 के लिए भी काम किया।

— नव

यह एक बुरा उपाय है। कारण: अनुक्रमणिका का मतलब असीम रूप से लंबा होना नहीं है। जब आप किसी चीज़ के लिए एक अद्वितीय इंडेक्स लागू करते हैं, तो आप चाहते हैं कि इंडेक्स अधिकांश समय निश्चित हो। इसका मतलब है कि आप सामान की तरह अद्वितीय बनाना चाहिएemail , लेकिन आप ईमेल हैश करना चाहिए और उस एक अद्वितीय बनाना चाहिए। कच्चे स्ट्रिंग-डेटा के विपरीत, हैश निश्चित चौड़ाई है और बिना मुद्दों के अनुक्रमित और अद्वितीय बनाया जा सकता है। समस्या को समझने के बजाय, आप भयानक प्रथाओं का प्रसार कर रहे हैं जो पैमाने पर नहीं हैं।

— NB

Answer 19

अपनी टक्कर बदलो। आप utf8_general_ci का उपयोग कर सकते हैं जो लगभग सभी का समर्थन करता है

Comments

"लगभग" एक बहुत अच्छा संकेत है कि यह एक दीर्घकालिक समाधान नहीं है

— निको हासे

Answer 20

सिर्फ टेबल बनाते समय बदलने utf8mb4से utf8मेरी समस्या हल हो गई। उदाहरण के लिए: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;से CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;।

Answer 21

इसे ठीक करने के लिए, यह मेरे लिए एक आकर्षण की तरह काम करता है।

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Comments

मैं इस बात की पुष्टि करता हूं कि मेरा मुद्दा डेटाबेस कोलेशन भी था। मेरे पास इसके लिए कोई स्पष्टीकरण नहीं है। मैं mysql v5.6.32 का उपयोग करता हूं और DB collation utf8mb4_unicode_ci था।

— महिंद्रा

Answer 22

नीचे दिए गए कॉलम के आधार पर, उन 2 चर स्ट्रिंग कॉलमों का उपयोग utf8_general_ciकोलाजेशन ( utf8चारसेट निहित है) के रूप में किया जाता है।

MySQL में, utf8चारसेट प्रत्येक वर्ण के लिए अधिकतम 3 बाइट्स का उपयोग करता है । इस प्रकार, इसे 500 * 3 = 1500 बाइट्स आवंटित करने की आवश्यकता होगी, जो कि 767 बाइट्स MySQL की अनुमति से बहुत अधिक है। इसलिए आपको यह 1071 त्रुटि मिल रही है।

दूसरे शब्दों में, आपको वर्ण की बाइट प्रतिनिधित्व के आधार पर वर्ण गणना की गणना करने की आवश्यकता है क्योंकि प्रत्येक वर्णक एक एकल बाइट प्रतिनिधित्व नहीं है (जैसा कि आपने माना है।) utf8MySQL में IE का उपयोग प्रति वर्ण 767 या 3≈255 प्रति वर्ण में सबसे अधिक होता है। वर्ण, और के लिए utf8mb4, एक सबसे 4 बाइट प्रतिनिधित्व में, 767 / 4≈191 अक्षर।

यह भी ज्ञात है कि MySQL

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

Answer 23

मुझे यह पता लगाने में मदद मिली कि अधिकतम लंबाई का उल्लंघन करने वाले सूचकांक में कौन से कॉलम थे:

SELECT
  c.TABLE_NAME As TableName,
  c.COLUMN_NAME AS ColumnName,
  c.DATA_TYPE AS DataType,
  c.CHARACTER_MAXIMUM_LENGTH AS ColumnLength,
  s.INDEX_NAME AS IndexName
FROM information_schema.COLUMNS AS c
INNER JOIN information_schema.statistics AS s
  ON s.table_name = c.TABLE_NAME
 AND s.COLUMN_NAME = c.COLUMN_NAME 
WHERE c.TABLE_SCHEMA = DATABASE()
  AND c.CHARACTER_MAXIMUM_LENGTH > 191 
  AND c.DATA_TYPE IN ('char', 'varchar', 'text')

Answer 24

कृपया जाँच करें कि sql_modeक्या है

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

अगर यह है, तो बदलो

sql_mode=NO_ENGINE_SUBSTITUTION

या

अपने सर्वर को अपने my.cnf फ़ाइल को फिर से शुरू करें (निम्नलिखित डालकर)

innodb_large_prefix=on

Answer 25

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

बैकअप (बिना अनुप्रेषित)

# mysqldump -u root -p databasename -r bkp.sql

पुनर्स्थापना (बिना <पुनर्निर्देशित)

# mysql -u root -p --default-character-set=utf8 databasename
mysql> SET names 'utf8'
mysql> SOURCE bkp.sql

त्रुटि "निर्दिष्ट कुंजी बहुत लंबी थी; अधिकतम कुंजी लंबाई 767 बाइट्स" सरल गायब हो गई।

Answer 26

सूचकांक लंबाई और MySQL / MariaDB

---

लारवेल डिफ़ॉल्ट रूप से सेट किए गए utf8mb4 वर्ण का उपयोग करता है , जिसमें डेटाबेस में " इमोजीस " के भंडारण के लिए समर्थन शामिल है। यदि आप 5.7.7 रिलीज़ से पुराने MySQL का संस्करण चला रहे हैं या 10.2.2 रिलीज़ से अधिक पुराना MariaDB है, तो आपको उनके लिए अनुक्रमणिका बनाने के लिए MySQL के लिए माइग्रेशन द्वारा उत्पन्न डिफ़ॉल्ट स्ट्रिंग लंबाई को मैन्युअल रूप से कॉन्फ़िगर करने की आवश्यकता हो सकती है। आप अपने AppServiceProvider के भीतर स्कीमा :: defaultStringLength विधि को कॉल करके इसे कॉन्फ़िगर कर सकते हैं :

use Illuminate\Support\Facades\Schema;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

वैकल्पिक रूप से, आप अपने डेटाबेस के लिए innodb_large_prefix विकल्प सक्षम कर सकते हैं। इस विकल्प को ठीक से सक्षम करने के निर्देशों के लिए अपने डेटाबेस के प्रलेखन का संदर्भ लें।

ब्लॉग से संदर्भ: https://www.scratchcode.io/specified-key-too-long-error-in-arara/

आधिकारिक लार्वा प्रलेखन से संदर्भ: https://laravel.com/docs/5.7/migrations

Answer 27

यदि आप कुछ ऐसा बना रहे हैं:

CREATE TABLE IF NOT EXISTS your_table (
  id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
  name varchar(256) COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY name (name)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

यह कुछ ऐसा होना चाहिए

CREATE TABLE IF NOT EXISTS your_table (
      id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
      name varchar(256) COLLATE utf8mb4_bin NOT NULL,
      PRIMARY KEY (id)
    ) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

लेकिन आपको कोड से उस कॉलम की विशिष्टता की जाँच करने की आवश्यकता है या एक नया कॉलम जोड़ने के लिए MD5 या varchar कॉलम का SHA1

Comments

फिर आपकी अनोखी चाबी खो गई। मुझे लगता है कि बेहतर तरीका बस 191 के नाम की लंबाई कम है

— haudoing

यदि यह मूल DB सुविधा है तो प्रोग्रामेटिक रूप से विशिष्टता की जांच क्यों करें?

— पावेल टॉमकिल

Answer 28

उपसर्ग सीमाओं के कारण यह त्रुटि होगी। 5.7 से पहले MySQL संस्करणों में InnoDB तालिकाओं के लिए 767 बाइट्स को उपसर्ग सीमा कहा गया है। यह MyISAM तालिकाओं के लिए 1,000 बाइट्स लंबा है। MySQL संस्करण 5.7 और इसके बाद के संस्करण में इस सीमा को बढ़ाकर 3072 बाइट्स कर दिया गया है।

आपको त्रुटि प्रदान करने वाली सेवा पर निम्नलिखित को चलाने से आपकी समस्या का समाधान होना चाहिए। इसे MYSQL CLI में चलाया जाना है।

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=on;
SET GLOBAL innodb_large_prefix=on;

Answer 29

शिकायत सूचकांक क्षेत्र के
परिवर्तन को " लैटिन 1 " में बदल दें, अर्थात वैकल्पिक तालिका में बदलें myfield myfield varchar (600) CHARACTER SET latin1 DEFAULT NULL;
लैटिन 1 चार के बजाय एक चरित्र के लिए एक बाइट लेता है

Comments

और क्या होगा अगर वह गैर-लैटिन 1 अक्षर डालने की कोशिश करेगा ?

— पावेल टॉमकील

यह सबसे बुरा काम है। कभी मत करो।

— सेबास

मेरे मामले में इसका एक स्तंभ पर जो केवल हेक्स वर्णों के साथ पथ नाम संग्रहीत करता है ... तो यह किसी के लिए एक समाधान हो सकता है। यह वास्तव में इस बात पर निर्भर करता है कि आप क्या संग्रह करना चाहते हैं ...

— कोडवर्ड

मुझे इसे कम करना पड़ा, क्योंकि 2016AD में लैटिन 1 का उपयोग करना समाधान नहीं है। मेरे पास अभी भी भयानक दुःस्वप्न हैं समय के बारे में जो हमें 2007 में लैटिन 1 से utf8 तक डेटाबेस को बदलना था। उह। सुंदर नहीं। बिल्कुल भी।

— बेत लाम्ड

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

— एलेक्स डेग 26:16

Answer 30

यदि आप innodb_log_file_sizeहाल ही में बदल गए हैं, तो पिछले मान को पुनर्स्थापित करने का प्रयास करें जो काम किया था।