utf8_bin बनाम utf_unicode_ci

Question

मेरे तालिका वेबसाइट

Website_Name//column name 
Google 
Facebook 
Twitter 
Orkut 
Frype 
Skype 
Yahoo 
Wikipedia 

मैं मैं मिलान तो मेरी क्वेरी utf8_bin का उपयोग वेबसाइट में विकिपीडिया खोज करने के लिए

Select Website_Name from Website where lower(Website_Name)='wikipedia' 

है और अगर मैं utf8_unicode_ci फिर मेरे चयन क्वेरी का उपयोग खोज करने के लिए विकिपीडिया वेबसाइट में

Select Website_Name from Website where Website_Name='wikipedia' 

अब मैं जानना चाहता हूं कि कौन सा संयोजन सबसे अच्छा है प्रश्नों के कारण

Answer 1

यह आपकी आवश्यकता पर निर्भर करता है।

utf8_bin collation पूरी तरह से अपने यूनिकोड code point मानों पर आधारित तारों की तुलना करता है। यदि सभी कोड बिंदुओं के समान मान हैं, तो तार बराबर हैं। हालांकि, यह अलग हो जाता है जब आपके पास अंक (संयोजन बनाम विघटित) या वर्णों के संयोजन के लिए अलग-अलग संरचना के साथ तार होते हैं, लेकिन समान कोड बिंदु मान नहीं होते हैं। कुछ मामलों में, utf8_bin का उपयोग करने से परिणामस्वरूप स्ट्रिंग मेल नहीं खाती हैं जब आप उन्हें उम्मीद करते हैं। सैद्धांतिक रूप से, utf8_bin सबसे तेज़ है क्योंकि स्ट्रिंग पर कोई यूनिकोड सामान्यीकरण लागू नहीं होता है, लेकिन हो सकता है कि आप जो भी चाहते हों।

utf8_general_ci भाषा-विशिष्ट नियमों का उपयोग करके यूनिकोड सामान्यीकरण लागू करता है और स्ट्रिंग केस की तुलनात्मक रूप से तुलना करता है। utf8_general_cs वही करता है, लेकिन स्ट्रिंग केस-सेंसिटिवली की तुलना करता है।

Answer 2

व्यक्तिगत रूप से मैं utf8_unicode_ci के साथ जाऊंगा, यदि आप उम्मीद करते हैं कि आमतौर पर उन पत्रों के लिए लेटरकेस महत्वपूर्ण नहीं है जो आप खोजना चाहते हैं।

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

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

mysql> create table utf8 (name varchar(24) charset utf8 collate utf8_general_ci, primary key (name)); 
Query OK, 0 rows affected (0.14 sec) 

mysql> insert into utf8 values ('Roland'); 
Query OK, 1 row affected (0.00 sec) 

mysql> insert into utf8 values ('roland'); 
ERROR 1062 (23000): Duplicate entry 'roland' for key 'PRIMARY' 
mysql> select * from utf8 where name = 'roland'; 
+--------+ 
| name | 
+--------+ 
| Roland | 
+--------+ 
1 row in set (0.00 sec) 

mysql> select * from utf8 where binary name = 'roland'; 
Empty set (0.01 sec) 

यह कम या ऊपरी उपयोग करते हुए, के बाद से उन मामलों में, MySQL पहले कॉलम मूल्य की एक प्रतिलिपि बनाने और उसके lettercase संशोधित, और फिर तुलना लागू करने के लिए की जरूरत है की तुलना में बहुत तेजी से होना चाहिए। जगह में बिनरी के साथ यह मैचों को खोजने के लिए पहले इंडेक्स का उपयोग करेगा, और उसके बाद कोड-पॉइंट तुलना द्वारा कोड-पॉइंट करें, जब तक कि यह नहीं मिलता कि मान बराबर नहीं हैं, जो आमतौर पर तेज़ होगा।

* @ORM\Table(name = "Table", options={"collate"="utf8_bin"}) 

चूंकि मेरे समग्र प्राथमिक कुंजी के कुछ पाठ क्षेत्रों में शामिल हैं:

Answer 3

मैं 'utf8_unicode_ci' जो सिद्धांत द्वारा डिफ़ॉल्ट है उपयोग कर रहा था, मैं करने के लिए इसे बदलना पड़ा। अफसोस की बात है 'utf8_unicode_ci' हल "poistný" और "poistny" एक ही प्राथमिक कुंजी मूल्य के रूप में और फ्लश डालने सिद्धांत में दुर्घटना के साथ समाप्त हो गया। मैं समग्र प्राथमिक कुंजी के एक हिस्से के संयोजन को आसानी से नहीं बदल सका, तालिका को छोड़ना और फिर से बनाना था। उम्मीद है कि यह किसी और के लिए समय बचाता है ..