यदि मैं MySQL में कॉलम के संयोजन को बदलता हूं तो मौजूदा डेटा का क्या होगा?

Question

मैं MySQL डेटाबेस सर्वर के साथ एक उत्पादन अनुप्रयोग चला रहा हूँ। मैं कॉलम के संयोजन को latin से utf8_unicode पर सेट करना भूल जाता हूं, जिसके परिणामस्वरूप बहु भाषा डेटा वाले कॉलम को सहेजते समय अजीब डेटा होता है।

मेरा सवाल यह है कि, यदि मैं अपने collation को utf8_unicode में बदलता हूं तो मेरे मौजूदा डेटा के साथ क्या होगा? क्या यह मौजूदा डेटा को नष्ट या दूषित करेगा या डेटा रहेगा, लेकिन नया डेटा utf8 के रूप में सहेजा जाएगा जैसा इसे करना चाहिए?

मैं phpMyAdmin वेब क्लाइंट के साथ बदल जाऊंगा।

Answer 1

एक VARCHAR स्तंभ सेट के साथ MySQL 5.1 में एक त्वरित परीक्षण चल रहा है latin1_bin लिए मैं कुछ गैर-लैटिन वर्ण

INSERT INTO Test VALUES ('英國華僑'); 

मैं उन्हें चुनें और बकवास मिलता है (उम्मीद के रूप में) डाला।

SELECT text from Test; 

text 
???? 

मैं तो utf8_unicode करने के लिए स्तंभ का मिलान बदल गया है और फिर से भाग गया का चयन देता है और यह एक ही परिणाम से पता चलता

text 
???? 

यह मैं क्या उम्मीद करेंगे है - यह डेटा रखेगा और डेटा कचरा रहेगा, क्योंकि जब डेटा डाला गया था तो स्तंभ ने अतिरिक्त वर्ण जानकारी खो दी और बस एक डाला? प्रत्येक गैर-लैटिन चरित्र के लिए और ???? के लिए कोई रास्ता नहीं है ???? फिर से 英國 華僑 बनने के लिए।

आपका डेटा जगह में रहेगा लेकिन यह तय नहीं किया जाएगा।

Answer 2

मान्य डेटा ठीक से परिवर्तित किया जाएगा:

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

http://dev.mysql.com/doc/refman/5.5/en/alter-table.html

... और अधिक विशेष:

एक विशेष वर्ण सेट का उपयोग करने के एक द्विआधारी या nonbinary स्ट्रिंग स्तंभ बदलने के लिए, ALTER तालिका का उपयोग करें। सफल रूपांतरण होने के लिए, में से एक निम्न स्थितियों के लागू करना चाहिए: [...] स्तंभ एक nonbinary डेटा प्रकार (CHAR, VARCHAR, पाठ) है, तो इसकी सामग्री स्तंभ चरित्र में एन्कोड किया जाना चाहिए सेट करें, कुछ अन्य चरित्र सेट नहीं। यदि सामग्री एक अलग वर्ण सेट में एन्कोड किए गए हैं, तो आप कॉलम को का उपयोग बाइनरी डेटा प्रकार पहले और फिर वांछित वर्ण सेट के साथ एक गैर-कॉलम कॉलम में परिवर्तित कर सकते हैं।

http://dev.mysql.com/doc/refman/5.1/en/charset-conversion.html

तो आपकी समस्या अमान्य डेटा, उदाहरण के लिए, एक अलग वर्ण सेट में इनकोडिंग डेटा है। मैंने दस्तावेज द्वारा सुझाए गए सुझाव की कोशिश की है और यह मूल रूप से मेरे डेटा को बर्बाद कर दिया गया है, लेकिन इसका कारण यह है कि मेरा डेटा पहले से ही खो गया था: SELECT column, HEX(column) FROM table चलाते हुए दिखाया गया कि मल्टीबाइट वर्ण 0x3F (यानी, ? लैटिन 1 में प्रतीक के रूप में डाला गया था)। मेरा MySQL स्टैक यह पता लगाने के लिए पर्याप्त स्मार्ट था कि इनपुट डेटा लैटिन 1 नहीं था और इसे "संगत" में परिवर्तित कर दिया गया था। और एक बार डेटा खत्म हो जाने पर, आप इसे वापस नहीं प्राप्त कर सकते हैं।() पता लगाने के लिए आप अभी भी अपने डेटा है तो

1. उपयोग हेक्स:

   सारांश में।

2. अपनी परीक्षाओं को अपनी तालिका में कॉपी करें।

Answer 3

लेख http://mysqldump.azundris.com/archives/60-Handling-character-sets.html इस पर चर्चा करता है और यह भी दिखाता है कि क्या होगा।

कृपया ध्यान दें कि आप एक संग्रह के साथ एक वर्ण सेट (वास्तव में एक एन्कोडिंग) मिश्रण कर रहे हैं।

एक वर्ण सेट डिस्क पर बाइट्स में एक स्ट्रिंग के भौतिक प्रतिनिधित्व को परिभाषित करता है। HEX() फ़ंक्शन का उपयोग करके आप इसे दृश्यमान बना सकते हैं, उदाहरण के लिए SELECT HEX(str) FROM t WHERE id = 1 यह देखने के लिए कि MySQL आपकी स्ट्रिंग के बाइट्स को कैसे संग्रहीत करता है। SET NAMES .... के साथ परिभाषित आपके कनेक्शन के चरित्र सेट के आधार पर, MySQL आपको क्या प्रदान करता है, अलग हो सकता है।

एक संयोजन एक क्रमबद्ध क्रम है। यह चरित्र सेट पर निर्भर है। उदाहरण के लिए, आपका डेटा लैटिन 1 वर्ण सेट में हो सकता है, लेकिन इसे दो जर्मन सॉर्ट ऑर्डर लैटिन 1_german1_ci या latin1_german2_ci के अनुसार आदेश दिया जा सकता है। आपकी पसंद के आधार पर, उमलॉट्स जैसे ö या तो ओई या ओ के रूप में सॉर्ट करेंगे।

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

जब आप एक संयोजन बदल रहे हैं, तो डेटा का सॉर्ट ऑर्डर बदलता है लेकिन डेटा ही नहीं। यदि आप जिस कॉलम को बदल रहे हैं वह इंडेक्स का हिस्सा नहीं है, तो फ़्रेम फ़ाइल को फिर से लिखने के अलावा कुछ भी करने की आवश्यकता नहीं है, और MySQL के पर्याप्त हाल के संस्करणों को और अधिक नहीं करना चाहिए।

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

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

Answer 4

मेरा सवाल यह है कि, यदि मैं अपना अब utf8_unicode पर collation बदलता हूं तो मेरे मौजूदा डेटा के साथ क्या होगा?

उत्तर: यदि आप utf8_unicode_ci में बदलते हैं, तो आपके मौजूदा डेटा के साथ कुछ भी नहीं होगा (जो पहले से ही भ्रष्ट है और जब तक आप इसे संशोधित नहीं करते हैं तब तक भ्रष्ट रहें)।

क्या यह मौजूदा डेटा को नष्ट या दूषित करेगा या डेटा रहेगा, लेकिन नया डेटा utf8 के रूप में सहेजा जाएगा?

उत्तर: utf8_unicode_ci में बदलने के बाद, मौजूदा डेटा नष्ट नहीं होगा। यह पहले की तरह ही रहेगा (जैसे ????)। हालांकि, यदि आप यूनिकोड वर्ण वाले नए डेटा को सम्मिलित करते हैं, तो यह सही ढंग से संग्रहीत किया जाएगा।

मैं phpMyAdmin वेब क्लाइंट के साथ बदल जाऊंगा।

उत्तर: बेशक, आप> तालिका विकल्प संचालन करने के लिए जा

Answer 5

चेतावनी द्वारा phpMyAdmin साथ मिलान बदल सकते हैं! कुछ समस्याओं

ALTER TABLE ... CONVERT TO ... 

कुछ हल कर रहे हैं के माध्यम से हल कर रहे हैं 2-चरणीय प्रक्रिया

ALTER TABLE ... MODIFY ... VARBINARY... 
ALTER TABLE ... MODIFY ... VARCHAR... 

के माध्यम से आप गलत एक कार्य करें, तो आप एक बदतर गड़बड़ होगा!

1. SELECT HEX(col), col ... क्या आपके पास वास्तव में है यह देखने के लिए।
2. अध्ययन यह है कि क्या मामला आपके पास देखने के लिए: http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases

: Trouble with utf8 characters; what I see is not what I stored

सही ठीक, इन मामलों के आधार पर निष्पादित करें