अतीत में, केवल utf8
था; <स्ट्राइक>भविष्य में, utf8mb4
डिफ़ॉल्ट वर्ण सेट होगा।स्ट्राइक> अब utf8mb4
डिफ़ॉल्ट वर्ण सेट है।
अतीत में, _general_ci
डिफ़ॉल्ट संयोजन था; फिर _unicode_ci
(यूनिकोड 4.0) बेहतर था, तब _unicode_520_ci
(यूनिकोड 5.20)। भविष्य में (MySQL 8.0), डिफ़ॉल्ट होगा _0900_ci_ai
(यूनिकोड 9.0)।
इस बीच, सड़क MySQL की पिछली गलतियों से उत्पन्न गड्ढों से भरी है। और WP डिज़ाइनर एक बड़े टैंक में गाड़ी चला रहे हैं जो गड्ढों पर ध्यान नहीं देता है।
MySQL 5.6 एक बड़ा गड्ढा था जिसने बहुत से WP उपयोगकर्ता को निगल लिया था क्योंकि WP इंडेक्स के साथ-साथ इंडेक्स पर 767 की सीमा अत्यधिक लंबे VARCHAR(255)
पर थी। और utf8mb4
. का उपयोग करने की संभावना . आप 5.7.17 के बाद इसे अच्छी तरह से पार कर चुके हैं। (आपका भविष्य 8.0 पर जाना कम ऊबड़-खाबड़ होगा।)
यानी, 5.7.7+ पर नए बनाए गए डेटाबेस/टेबल/कॉलम को 767 समस्या का अनुभव नहीं होना चाहिए, लेकिन पुराने संस्करणों (5.5.3+) से माइग्रेट की गई चीज़ों में समस्याएँ हो सकती हैं, खासकर अगर कोई चीज़ आपको utf8mb4 में बदलने का कारण बनती है।पी>
क्या करें? मेरे पास शायद सभी विकल्पों का पता लगाने की कोशिश में जगह खत्म हो जाएगी। तो डेटा का इतिहास, अपग्रेड पथ (यदि कोई हो), वर्तमान सेटिंग्स, ROW_FORMAT
प्रदान करें तालिकाओं में से, CHARACTER SET
और COLLATION
कॉलम का, आउटपुट SHOW VARIABLES LIKE 'char%';
आपको कहाँ होना चाहिए? 5.7.7+ के लिए, utf8mb4
और utf8mb4_unicode_520_ci
जहां व्यावहारिक हो। वह वर्णसेट आपको इमोजी और सभी चीनी (utf8 नहीं) देता है। वह संयोजन सबसे अच्छा उपलब्ध है, हालांकि आपको यह नोटिस करने के लिए कड़ी मेहनत करनी पड़ सकती है कि यह कहां मायने रखता है।
नोट:कोलेशन नाम का पहला भाग एकमात्र कैरेक्टर सेट है जिसके साथ यह काम करता है। वह है utf8_unicode_ci
utf8mb4
. के साथ काम नहीं करता है ।