MySQL'de "Harmanlama karışımları geçersiz" hatası sorun giderme

MySQL bir saklı yordam ile bir seçim yapmaya çalışırken aşağıdaki hatayı alıyorum.

'=' İşlemi için geçersiz harmanlama karışımı (latin1_general_cs, IMPLICIT) ve (latin1_general_ci, IMPLICIT)

Burada neyin yanlış olabileceği hakkında bir fikrin var mı?

Tablonun latin1_general_cive nerede yan tümcesindeki sütunun harmanlanması latin1_general_cs.

Bunun nedeni genellikle iki uyumsuz harmanlama dizesinin karşılaştırılması veya farklı bir harmanlamadaki verilerin birleştirilmiş bir sütuna seçilmesidir.

Yan tümcesi COLLATEsorguda kullanılan harmanlamayı belirtmenizi sağlar.

Örneğin, aşağıdaki WHEREfıkra her zaman gönderdiğiniz hatayı verecektir:

WHERE 'A' COLLATE latin1_general_ci = 'A' COLLATE latin1_general_cs

Çözümünüz, sorgudaki iki sütun için paylaşılan bir harmanlama belirtmektir. İşte COLLATEcümleyi kullanan bir örnek :

SELECT * FROM table ORDER BY key COLLATE latin1_general_ci;

Başka bir seçenek de BINARYoperatörü kullanmaktır :

BINARY str, CAST (str AS BINARY) için kısaltmadır.

Çözümünüz şöyle görünebilir:

SELECT * FROM table WHERE BINARY a = BINARY b;

veya,

SELECT * FROM table ORDER BY BINARY a;

TL; DR

Dizelerden birinin (veya her ikisinin) harmanlamasını eşleşecek şekilde değiştirin veya COLLATEifadenize bir cümle ekleyin .

1. Zaten bu "harmanlama" şeyleri nedir?

   Genel olarak Karakter Kümeleri ve Harmanlamalar altında belgelendiği gibi :

   Bir karakter kümesi sembol ve kodlamaların kümesidir. Bir harmanlama bir karakter kümesindeki karakterleri karşılaştırmak için bir kurallar kümesidir. Hayali bir karakter seti örneği ile ayrımı netleştirelim.

   Dört harfli bir alfabemiz olduğunu varsayın: “ A”, “ B”, “ a”, “ b”. Her harfe bir sayı veririz: “ A” = 0, “ B” = 1, “ a” = 2, “ b” = 3. “ A” harfi bir semboldür, 0 rakamı “ ” için kodlamadırA ve hepsinin kombinasyonu dört harf ve kodlamaları bir karakter kümesidir .

   “Dize A” ve “ B” olmak üzere iki dize değerini karşılaştırmak istediğimizi varsayalım . Bunu yapmanın en basit yolu şu kodlamalara bakmaktır: “ A” için 0 ve “ ” için 1 B. 0 1'den Aküçük olduğu için “ B” “ ” den küçüktür . Az önce yaptığımız karakter setimize bir harmanlama uygulamak. Harmanlama bir dizi kuraldır (bu durumda yalnızca bir kural): “kodlamaları karşılaştırın.” Bunu mümkün olan en basit harmanlamalara ikili harmanlama olarak adlandırıyoruz.

   Peki ya küçük ve büyük harflerin eşdeğer olduğunu söylemek istersek? (1) küçük harfleri “tedavi: Sonra en az iki kural olurdu a” ve “ beşdeğer olarak” den “ A” ve “ B”; (2) daha sonra kodlamaları karşılaştırın. Buna büyük / küçük harfe duyarlı olmayan bir harmanlama diyoruz . İkili bir harmanlamadan biraz daha karmaşıktır.

   Gerçek hayatta, çoğu karakter setinde birçok karakter vardır: sadece “ A” ve “ B” değil, tüm alfabe, bazen birden fazla alfabe veya binlerce karakter içeren doğu yazı sistemleri, birçok özel sembol ve noktalama işareti bulunur. Ayrıca gerçek hayatta, çoğu harmanlamanın sadece harf harflerini ayırt edip etmeme konusunda değil, aynı zamanda aksanları ayırt edip etmeme konusunda da birçok kuralı vardır (“aksan” bir karaktere Almanca “ Ö” daki gibi bir işarete eklenmiş bir işarettir ) ve çok karakterli eşleştirmeleri ( iki Alman harmanlamasından birinde “ Ö” = “ OE” kuralı gibi ).

   Diğer örnekler Harmanlamanın Etkisi Örnekleri altında verilmektedir .

2. Tamam, ancak MySQL belirli bir ifade için hangi harmanlamayı kullanacağına nasıl karar verir?

   İfadelerin Harmanlanması altında belgelendiği gibi :

   İfadelerin büyük çoğunluğunda, bir karşılaştırma işlemini çözmek için MySQL'in kullandığı harmanlama açıktır. Örneğin, aşağıdaki durumlarda, harmanlamanın sütunun harmanlaması olduğu açık olmalıdır charset_name:

   SELECT x FROM T ORDER BY x;
   SELECT x FROM T WHERE x = x;
   SELECT DISTINCT x FROM T;

   Bununla birlikte, birden fazla işlenen ile belirsizlik olabilir. Örneğin:

   SELECT x FROM T WHERE x = 'Y';

   Karşılaştırma sütun xveya harf dizgesinin harmanlamasını kullanmalı 'Y'mıdır? Hem xve 'Y'alfabe var, bu yüzden hangi harmanlama önceliklidir?

   Standart SQL, eskiden “zorlanabilirlik” denilen kuralları kullanarak bu tür soruları çözer.

   [ deletia ]

   MySQL, belirsizlikleri çözmek için aşağıdaki kurallara sahip zorlama değerlerini kullanır:

   • En düşük zorlama değerine sahip harmanlamayı kullanın.

   • Her iki taraf da aynı zorlamaya sahipse, o zaman:

     • Her iki taraf Unicode veya her iki taraf Unicode değilse, bu bir hatadır.

     • Kenarlardan birinde Unicode karakter kümesi varsa ve başka bir tarafta Unicode olmayan karakter kümesi varsa, Unicode karakter kümesi olan taraf kazanır ve Unicode olmayan tarafa otomatik karakter kümesi dönüşümü uygulanır. Örneğin, aşağıdaki ifade bir hata döndürmez:

       SELECT CONCAT(utf8_column, latin1_column) FROM t1;

       Karakter kümesine utf8ve ile aynı harmanlamaya sahip bir sonuç döndürür utf8_column. Değerlerini birleştirmeden önce latin1_columnotomatik olarak dönüştürülür utf8.

     • Aynı karakter kümesinden işlenenler içeren ancak bir _binharmanlama ile a _civeya _csharmanlamayı karıştıran bir işlem için _binharmanlama kullanılır. Bu, ikili olmayan ve ikili dizeleri karıştıran işlemlerin işlenenleri ikili dizeler olarak nasıl değerlendirdiğine benzer; tek fark, veri türleri yerine harmanlamalar içindir.

3. Peki "yasa dışı harmanlama karışımı" nedir?

   Bir ifade farklı harmanlamalardan oluşan ancak eşit zorlamadan oluşan iki dizeyi karşılaştırdığında ve zorlama kuralları çatışmanın çözümlenmesine yardımcı olamadığında "yasa dışı harmanlama karışımı" oluşur. Yukarıdaki alıntıda üçüncü madde işareti altında açıklanan durumdur.

   Illegal mix of collations (latin1_general_cs,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation '='Soruda verilen özel hata , bize Unicode olmayan iki eşit karakter dizisi arasında bir eşitlik karşılaştırması olduğunu söyler. Ayrıca, harmanlamaların ifadede açık bir şekilde verilmediğini, ancak dizelerin kaynaklarından (sütun meta verileri gibi) ima edildiğini belirtir.

4. Bu çok iyi, ama böyle hataları nasıl çözerim?

   Yukarıda belirtilen manuel ekstrelerin önerdiği gibi, bu sorun, ikisi mantıklı ve tavsiye edilmesi gereken birkaç yolla çözülebilir:

   • Dizelerden birinin (veya her ikisinin) harmanlamasını eşleşecek şekilde değiştirin ve artık belirsizlik kalmayacak.

     Bunun nasıl yapılacağı dizenin nereden geldiğine bağlıdır: Değişmez ifadeler collation_connectionsistem değişkeninde belirtilen harmanlamayı alır ; tablolardaki değerler, sütun meta verilerinde belirtilen harmanlamayı alır.

   • Bir dizeyi zorunlu olmaya zorlayın.

     Yukarıdaki alıntıyı atladım:

     MySQL, zorlanabilirlik değerlerini şu şekilde atar:

     • Açık bir COLLATEmaddenin 0 zorlaması vardır. (Hiç zorlanamaz.)

     • İki dizenin farklı harmanlamalarla birleştirilmesinin 1 zorlaması vardır.

     • Bir sütunun veya depolanmış bir rutin parametrenin veya yerel değişkenin harmanlanması 2'lik bir zorlamaya sahiptir.

     • “Sistem sabiti” ( USER()veya gibi işlevler tarafından döndürülen dize VERSION()) 3'lük bir zorlamaya sahiptir.

     • Bir hazır bilginin harmanlanması 4'lük bir zorlamaya sahiptir.

     • NULLveya türetilmiş NULLbir ifadenin 5 zorlaması vardır.

     Böylece COLLATE, karşılaştırmada kullanılan dizelerden birine bir cümle eklemek bu harmanlamayı kullanmaya zorlayacaktır.

   Diğerleri, yalnızca bu hatayı çözmek için dağıtılmış olsalardı, çok kötü bir uygulama olurdu:

   • Dizelerden birini (veya her ikisini) önceliğe sahip olmak için başka bir zorlama değerine sahip olmaya zorlayın.

     Kullanımı CONCAT()veya CONCAT_WS()1'lik bir coercibility ile bir dize neden olacaktır; ve (depolanmış bir rutin içindeyse) parametrelerin / yerel değişkenlerin kullanılması, 2 zorlaması olan dizelerle sonuçlanır.

   • Dizelerden birinin (veya her ikisinin) kodlamasını biri Unicode olacak ve diğeri olmayacak şekilde değiştirin.

     Bu, kod dönüştürme ile yapılabilir ; veya verilerin temeldeki karakter kümesini değiştirerek (örn. sütunu değiştirme , değişmez değerler için değiştirme veya istemciden farklı bir kodlama ile gönderme ve bir karakter kümesi tanıtıcısını değiştirme / ekleme). İstenen bazı karakterler yeni karakter kümesinde kodlanamazsa, kodlamanın değiştirilmesinin başka sorunlara yol açacağını unutmayın.CONVERT(expr USING transcoding_name)character_set_connectioncharacter_set_client

   • Dizelerden birinin (veya her ikisinin) kodlamalarını aynı olacak şekilde değiştirin ve ilgili _binharmanlamayı kullanmak için bir dizeyi değiştirin .

     Kodlamaları ve harmanlamaları değiştirme yöntemleri yukarıda detaylandırılmıştır. Bu yaklaşım, gerçekten, _binharmanlama tarafından sunulandan daha gelişmiş harmanlama kuralları uygulamak gerektiğinde çok az yararlı olacaktır .

Gelecekteki Google çalışanları için tartışmaya 2c'mi ekleme.

Bir varchar parametresi alınan özel işlevleri kullanırken aşağıdaki hatayı aldım benzer bir sorunu araştırıyordu :

Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and 
(utf8_general_ci,IMPLICIT) for operation '='

Aşağıdaki sorguyu kullanarak:

mysql> show variables like "collation_database";
    +--------------------+-----------------+
    | Variable_name      | Value           |
    +--------------------+-----------------+
    | collation_database | utf8_general_ci |
    +--------------------+-----------------+

Tablolar utf8_unicode_ci kullanılarak tanımlanırken DB utf8_general_ci kullandığını söyleyebildim :

mysql> show table status;
    +--------------+-----------------+
    | Name         | Collation       |
    +--------------+-----------------+
    | my_view      | NULL            |
    | my_table     | utf8_unicode_ci |
    ...

Görünümlerin NULL harmanlama olduğuna dikkat edin . Bu sorgu bir görünüm için null olsa bile, görünümlerin ve işlevlerin harmanlama tanımlarına sahip olduğu görülmektedir. Kullanılan harmanlama, görünüm / işlev oluşturulduğunda tanımlanan DB harmanlamasıdır.

Üzücü çözüm, hem db harmanlamasını değiştirmek hem de mevcut harmanlamayı kullanmaya zorlamak için görünümleri / işlevleri yeniden oluşturmaktı.

• Db'nin harmanlamasını değiştirme:

  ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;

• Tablo harmanlamasını değiştirme:

  ALTER TABLE mydb CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Umarım bu birisine yardım eder.

Bazen, özellikle büyük miktarlarda veri içeren veritabanlarında karakter kümelerini dönüştürmek tehlikeli olabilir. En iyi seçenek "ikili" operatörü kullanmak olduğunu düşünüyorum:

e.g : WHERE binary table1.column1 = binary table2.column1

Benzer bir sorun vardı, bir dize değişkeni ile FIND_IN_SET yordamı kullanmaya çalışıyordu .

SET @my_var = 'string1,string2';
SELECT * from my_table WHERE FIND_IN_SET(column_name,@my_var);

ve hatayı alıyordu

Hata Kodu: 1267. 'find_in_set' işlemi için geçersiz harmanlama karışımı (utf8_unicode_ci, IMPLICIT) ve (utf8_general_ci, IMPLICIT)

Kısa cevap:

Herhangi bir collation_YYYY değişkenini değiştirmenize gerek yok, sadece değişken bildiriminizin yanına doğru harmanlamayı ekleyin , yani

SET @my_var = 'string1,string2' COLLATE utf8_unicode_ci;
SELECT * from my_table WHERE FIND_IN_SET(column_name,@my_var);

Uzun cevap:

İlk olarak harmanlama değişkenlerini kontrol ettim:

mysql> SHOW VARIABLES LIKE 'collation%';
    +----------------------+-----------------+
    | Variable_name        | Value           |
    +----------------------+-----------------+
    | collation_connection | utf8_general_ci |
    +----------------------+-----------------+
    | collation_database   | utf8_general_ci |
    +----------------------+-----------------+
    | collation_server     | utf8_general_ci |
    +----------------------+-----------------+

Sonra tablo harmanlamasını kontrol ettim:

mysql> SHOW CREATE TABLE my_table;

CREATE TABLE `my_table` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `column_name` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=125 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Bu, tablonuz utf8_unicode_ci olarak yapılandırılırken değişkenimin varsayılan utf8_general_ci harmanlaması ile yapılandırıldığı anlamına gelir .

Değişken bildiriminin yanına COLLATE komutunu ekleyerek, değişken harmanlama tablo için yapılandırılan harmanlama ile eşleşir.

Tüm veritabanlarınızı ve tablolarınızı utf8'e dönüştüren bu komut dosyasını deneyebilirsiniz .

Değişmez değerler varsa çözüm.

Pentaho Veri Entegrasyonu kullanıyorum ve sql sözdizimini belirtmek için alamadım. Çok basit bir DB araması kullanıldığında "Geçersiz harmanlama karışımları (cp850_general_ci, COERCIBLE) ve (latin1_swedish_ci, COERCIBLE) '=' işlemi için hata oluştu"

Oluşturulan kod "SELECT DATA_DATE AS latest_DATA_DATE FROM hr_cc_normalised_data_date_v NEREDE PSEUDO_KEY =?"

Hikayeyi kısaltmak aramayı görmekti

mysql> show full columns from hr_cc_normalised_data_date_v;
+------------+------------+-------------------+------+-----+
| Field      | Type       | Collation         | Null | Key |
+------------+------------+-------------------+------+-----+
| PSEUDO_KEY | varchar(1) | cp850_general_ci  | NO   |     |
| DATA_DATE  | varchar(8) | latin1_general_cs | YES  |     |
+------------+------------+-------------------+------+-----+

bu da 'cp850_general_ci' nin nereden geldiğini açıklıyor.

Görünüm sadece 'SELECT' X ', ......' ile oluşturuldu. Bunun gibi manuel değişmez değerlere göre, karakter kümelerini ve harmanlamalarını, 'latin1' ve 'latin1_general_cs' olarak doğru olarak tanımlanan sunucu ayarlarından miras almalıdır. açıkça olmadı görüşün yaratılmasında zorladım

CREATE OR REPLACE VIEW hr_cc_normalised_data_date_v AS
SELECT convert('X' using latin1) COLLATE latin1_general_cs        AS PSEUDO_KEY
    ,  DATA_DATE
FROM HR_COSTCENTRE_NORMALISED_mV
LIMIT 1;

şimdi her iki sütun için latin1_general_cs gösterir ve hata gitti. :)

MySQL, aynı harmanlamaya zorlamadığı sürece karıştırma harmanlamalarından gerçekten hoşlanmamaktadır (bu, sizin durumunuzda açıkça mümkün değildir). Aynı harmanlamayı COLLATE deyimiyle kullanılmaya zorlayamaz mısınız? (veya BINARYvarsa daha basit kısayol ...).

Sorun yaşadığınız sütunlar "karma" ise, aşağıdakileri göz önünde bulundurun ...

"Karma" bir ikili dizgiyse, gerçekten BINARY(...)veri türü kullanmalısınız .

"Karma" bir hex dizgiyse, utf8'e ihtiyacınız yoktur ve karakter denetimleri vb. Nedeniyle bunlardan kaçınmalısınız. Örneğin, MySQL MD5(...)sabit uzunluklu 32 baytlık bir hex dizesi verir. SHA1(...)40 baytlık bir hex dizesi verir. Bu depolanabilir CHAR(32) CHARACTER SET ascii(veya sha1 için 40).

Veya, daha iyisi, UNHEX(MD5(...))içine saklayın BINARY(16). Bu sütun büyüklüğünün yarısını keser. (Ancak, SELECT HEX(hash) ...okunabilir olmasını sağlar.)

İki BINARYsütunu karşılaştırmanın harmanlama sorunu yoktur.

Çok ilginç ... Şimdi hazır olun. Tüm "harmanlama ekle" çözümlerine baktım ve bana, bunlar bant yardımı düzeltmeleri. Gerçek şu ki veritabanı tasarımı "kötü" idi. Evet, standart değişiklikler ve yeni şeyler ekleniyor, falan filan, ama kötü veritabanı tasarım gerçeğini değiştirmez. Sadece sorgumu işe almak için tüm SQL deyimleri üzerinde "harmanla" ekleme yolu ile gitmek reddediyorum. Benim için çalışan ve gelecekte kodumu düzeltmek ihtiyacını neredeyse ortadan kaldıracak tek çözüm, veritabanı / tabloları birlikte yaşayacağım ve uzun vadeli gelecek için benimsediğim karakter setiyle eşleşecek şekilde yeniden tasarlamak. Bu durumda, " utf8mb4 " karakter seti ile gitmeyi tercih ederim .

Yani burada "yasadışı" hata mesajıyla karşılaştığınızda çözüm veritabanı ve tabloları yeniden tasarlamaktır. Kulağa çok daha kolay ve hızlı. Verilerinizin dışa aktarılması ve bir CSV'den yeniden içe aktarılması bile gerekli olmayabilir. Veritabanının karakter kümesini değiştirin ve tablolarınızın tüm karakter kümesinin eşleştiğinden emin olun.

Size yol göstermek için şu komutları kullanın:

SHOW VARIABLES LIKE "collation_database";
SHOW TABLE STATUS;

Şimdi, burada ve orada "harmanla" eklemekten hoşlanırsanız ve kodlarınızı kuvvetler "geçersiz kılmalar" ile güçlendirirseniz, tahminim olun.

Olası bir çözüm tüm veritabanını UTF8'e dönüştürmektir (ayrıca bu soruya bakın ).

Harmanlama ile ilgili sorunun bir diğer kaynağı mysql.proctablodur. Depolama yordamlarınızın ve işlevlerinizin harmanlamalarını denetleyin:

SELECT
  p.db, p.db_collation, p.type, COUNT(*) cnt
FROM mysql.proc p
GROUP BY p.db, p.db_collation, p.type;

Ayrıca dikkat mysql.proc.collation_connectionve mysql.proc.character_set_clientsütunlar.

PhpMyAdmin yüklüyse, aşağıdaki bağlantıda verilen talimatları takip edebilirsiniz: https://mediatemple.net/community/products/dv/204403914/default-mysql-character-set-and-collation Harmanlamayı eşleştirmeniz gerekiyor veritabanının tüm tabloların yanı sıra tablo alanları ile ve daha sonra depolanan tüm yordamları ve işlevleri yeniden derleyin. Bununla her şey tekrar çalışmalı.

Kullandım ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;, ama işe yaramadı.

Bu sorguda:

Select * from table1, table2 where table1.field = date_format(table2.field,'%H');

Bu iş benim için:

Select * from table1, table2 where concat(table1.field) = date_format(table2.field,'%H');

Evet, sadece a concat.

Bu kodun SQL sorgusu / sorgularını veritabanında çalıştır içine konması gerekir

SQL QUERY PENCERESİ

ALTER TABLE `table_name` CHANGE `column_name` `column_name`   VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL;

Lütfen tablo_adı ve sütun_adı'nı uygun adla değiştirin.