उन लोगों के लिए जो अभी भी 2020 या उसके बाद इस प्रश्न पर पहुंच रहे हैं, ऐसे नए विकल्प हैं जो दोनों से बेहतर हो सकते हैं यहाँ इन। उदाहरण के लिए, utf8mb4_0900_ai_ci .
ये सभी कॉलेशन UTF-8 कैरेक्टर एन्कोडिंग के लिए हैं। अंतर इस बात में हैं कि टेक्स्ट को कैसे क्रमबद्ध और तुलना किया जाता है।
_unicode_ci और _general_ci हमारी अपेक्षा के अनुसार पाठ को छाँटने और तुलना करने के लिए नियमों के दो अलग-अलग सेट हैं। MySQL के नए संस्करण नियमों के नए सेट भी पेश करते हैं, जैसे _0900_ai_ci यूनिकोड 9.0 पर आधारित समकक्ष नियमों के लिए - और बिना समकक्ष _general_ci . के लिए प्रकार। इसे पढ़ने वाले लोगों को शायद _unicode_ci के बजाय इनमें से किसी एक नए कोलाज का उपयोग करना चाहिए या _general_ci . नीचे उन पुराने कोलाजों का विवरण केवल रुचि के लिए दिया गया है।
MySQL वर्तमान में पुराने, त्रुटिपूर्ण UTF-8 कार्यान्वयन से दूर हो रहा है। अभी के लिए, आपको utf8mb4 . का उपयोग करना होगा utf8 . के बजाय चरित्र एन्कोडिंग भाग के लिए, यह सुनिश्चित करने के लिए कि आपको निश्चित संस्करण मिल रहा है। त्रुटिपूर्ण संस्करण पश्चगामी संगतता के लिए बना रहता है, हालांकि इसे बहिष्कृत किया जा रहा है।
मुख्य अंतर
-
utf8mb4_unicode_ciसार्वभौमिक छँटाई और तुलना के लिए आधिकारिक यूनिकोड नियमों पर आधारित है, जो भाषाओं की एक विस्तृत श्रृंखला में सटीक रूप से छाँटता है। -
utf8mb4_general_ciछँटाई नियमों का एक सरलीकृत सेट है जिसका उद्देश्य गति में सुधार के लिए डिज़ाइन किए गए कई शॉर्ट-कट लेते हुए जितना अच्छा हो सके उतना करना है। यह यूनिकोड के नियमों का पालन नहीं करता है और इसके परिणामस्वरूप कुछ स्थितियों में अवांछनीय छँटाई या तुलना होगी, जैसे कि विशेष भाषाओं या वर्णों का उपयोग करते समय।आधुनिक सर्वरों पर, यह प्रदर्शन वृद्धि नगण्य के अलावा सभी होगी। यह ऐसे समय में तैयार किया गया था जब सर्वर के पास आज के कंप्यूटरों के CPU प्रदर्शन का एक छोटा सा अंश था।
utf8mb4_unicode_ci के लाभ utf8mb4_general_ci . से अधिक
utf8mb4_unicode_ci , जो छँटाई और तुलना के लिए यूनिकोड नियमों का उपयोग करता है, भाषाओं की एक विस्तृत श्रृंखला में सही छँटाई के लिए और विशेष वर्णों की एक विस्तृत श्रृंखला का उपयोग करते समय एक काफी जटिल एल्गोरिथ्म का उपयोग करता है। इन नियमों को भाषा-विशिष्ट सम्मेलनों को ध्यान में रखना चाहिए; हर कोई अपने पात्रों को उस क्रम में नहीं छाँटता जिसे हम 'वर्णमाला क्रम' कहते हैं।
जहां तक लैटिन (यानी "यूरोपीय") भाषाओं की बात है, यूनिकोड छँटाई और सरलीकृत utf8mb4_general_ci में बहुत अंतर नहीं है। MySQL में सॉर्ट करना, लेकिन अभी भी कुछ अंतर हैं:
-
उदाहरण के लिए, यूनिकोड कोलाज "ß" जैसे "ss", और "Œ" को "OE" की तरह सॉर्ट करता है, जैसा कि उन वर्णों का उपयोग करने वाले लोग सामान्य रूप से चाहते हैं, जबकि
utf8mb4_general_ciउन्हें एकल वर्णों के रूप में क्रमबद्ध करता है (संभवतः क्रमशः "s" और "e" की तरह)। -
कुछ यूनिकोड वर्णों को इग्नोरेबल के रूप में परिभाषित किया गया है, जिसका अर्थ है कि उन्हें क्रमबद्ध क्रम में नहीं गिना जाना चाहिए और तुलना को इसके बजाय अगले वर्ण पर ले जाना चाहिए।
utf8mb4_unicode_ciइन्हें ठीक से संभालता है।
गैर-लैटिन भाषाओं में, जैसे कि एशियाई भाषाएं या अलग-अलग अक्षर वाली भाषाएं, बहुत कुछ और हो सकती हैं यूनिकोड छँटाई और सरलीकृत utf8mb4_general_ci . के बीच अंतर छँटाई utf8mb4_general_ci . की उपयुक्तता उपयोग की जाने वाली भाषा पर बहुत अधिक निर्भर करेगा। कुछ भाषाओं के लिए, यह काफी अपर्याप्त होगा।
आपको क्या उपयोग करना चाहिए?
utf8mb4_general_ci . का उपयोग करने का लगभग निश्चित रूप से कोई कारण नहीं है अब, जैसा कि हमने उस बिंदु को पीछे छोड़ दिया है जहां सीपीयू की गति इतनी कम है कि प्रदर्शन अंतर महत्वपूर्ण होगा। आपका डेटाबेस लगभग निश्चित रूप से इसके अलावा अन्य बाधाओं से सीमित होगा।
अतीत में, कुछ लोगों ने utf8mb4_general_ci . का उपयोग करने की अनुशंसा की थी सिवाय जब सटीक छँटाई प्रदर्शन लागत को सही ठहराने के लिए पर्याप्त महत्वपूर्ण होने वाली थी। आज, वह प्रदर्शन लागत गायब हो गई है, और डेवलपर्स अंतर्राष्ट्रीयकरण को अधिक गंभीरता से ले रहे हैं।
एक तर्क दिया जाना चाहिए कि यदि सटीकता की तुलना में गति आपके लिए अधिक महत्वपूर्ण है, तो हो सकता है कि आप किसी भी प्रकार की छँटाई न करें। यदि आपको सटीक होने के लिए इसकी आवश्यकता नहीं है तो एल्गोरिदम को तेज़ बनाना आसान है। तो, utf8mb4_general_ci एक समझौता है जिसकी शायद गति कारणों से आवश्यकता नहीं है और शायद सटीकता कारणों के लिए भी उपयुक्त नहीं है।
एक और बात जो मैं जोड़ूंगा वह यह है कि भले ही आप जानते हैं कि आपका आवेदन केवल अंग्रेजी भाषा का समर्थन करता है, फिर भी इसे लोगों के नामों से निपटने की आवश्यकता हो सकती है, जिसमें अक्सर अन्य भाषाओं में उपयोग किए जाने वाले वर्ण शामिल हो सकते हैं जिनमें सही ढंग से क्रमबद्ध करना उतना ही महत्वपूर्ण है . हर चीज के लिए यूनिकोड नियमों का उपयोग करने से मन की शांति मिलती है कि बहुत ही स्मार्ट यूनिकोड लोगों ने सॉर्टिंग कार्य को ठीक से करने के लिए बहुत मेहनत की है।
भागों का क्या अर्थ है
सबसे पहले, ci केस-असंवेदनशील . के लिए है छँटाई और तुलना। इसका मतलब है कि यह टेक्स्ट डेटा के लिए उपयुक्त है, और मामला महत्वपूर्ण नहीं है। अन्य प्रकार के संयोजन हैं cs (केस-संवेदी) टेक्स्ट डेटा के लिए जहां मामला महत्वपूर्ण है, और bin , जहां एन्कोडिंग को मिलान करने की आवश्यकता है, बिट के लिए बिट, जो उन क्षेत्रों के लिए उपयुक्त है जो वास्तव में एन्कोडेड बाइनरी डेटा हैं (उदाहरण के लिए, बेस 64 सहित)। केस-संवेदी छँटाई कुछ अजीब परिणामों की ओर ले जाती है और केस-संवेदी तुलना के परिणामस्वरूप डुप्लिकेट मान केवल अक्षर के मामले में भिन्न हो सकते हैं, इसलिए केस-संवेदी कॉलेशन टेक्स्ट डेटा के पक्ष में गिर रहे हैं - यदि मामला आपके लिए महत्वपूर्ण है, तो अन्यथा अनदेखा विराम चिह्न और इसी तरह शायद भी महत्वपूर्ण है, और एक द्विआधारी संयोजन अधिक उपयुक्त हो सकता है।
अगला, unicode या general विशिष्ट छँटाई और तुलना नियमों को संदर्भित करता है - विशेष रूप से, जिस तरह से पाठ को सामान्यीकृत या तुलना किया जाता है। Utf8mb4 वर्ण एन्कोडिंग के लिए नियमों के कई अलग-अलग सेट हैं, unicode . के साथ और general दो हैं जो एक विशिष्ट भाषा के बजाय सभी संभावित भाषाओं में अच्छी तरह से काम करने का प्रयास करते हैं। नियमों के इन दो सेटों के बीच अंतर इस उत्तर का विषय है। ध्यान दें कि unicode यूनिकोड 4.0 से नियमों का उपयोग करता है। MySQL के हाल के संस्करण नियमों को जोड़ते हैं unicode_520 यूनिकोड 5.2, और 0900 . के नियमों का उपयोग करना ("यूनिकोड_" भाग को छोड़कर) यूनिकोड 9.0 के नियमों का उपयोग करते हुए।
और अंत में, utf8mb4 निश्चित रूप से वर्ण एन्कोडिंग आंतरिक रूप से उपयोग किया जाता है। इस उत्तर में मैं केवल यूनिकोड आधारित एनकोडिंग के बारे में बात कर रहा हूँ।
