Устранение ошибки "Недопустимое смешение коллажей" в mysql

Получаем ошибку ниже при попытке выполнить выбор в хранимой процедуре в MySQL.

Нелегальное сочетание сортировок (latin1_general_cs, IMPLICIT) и (latin1_general_ci, IMPLICIT) для операции '='

Любая идея о том, что здесь может быть неправильным?

Сравнение таблицы latin1_general_ci, а столбца в предложении where - latin1_general_cs.

ОТВЕТЫ

Ответ 1

Как правило, это вызвано сравнением двух строк несовместимого сопоставления или попыткой выделить данные другого сопоставления в объединенный столбец.

Предложение COLLATE позволяет указать параметры сортировки, используемые в запросе.

Например, следующее предложение WHERE всегда будет содержать сообщение об ошибке, которую вы опубликовали:

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

Ваше решение состоит в том, чтобы указать общее сопоставление для двух столбцов в запросе. Вот пример, который использует предложение COLLATE:

SELECT * FROM table ORDER BY key COLLATE latin1_general_ci;

Другой вариант - использовать оператор BINARY:

BINARY str - сокращение от CAST (st как AS BINARY).

Ваше решение может выглядеть примерно так:

SELECT * FROM table WHERE BINARY a = BINARY b;

или

SELECT * FROM table ORDER BY BINARY a;

Ответ 2

TL; DR

Либо измените сопоставление одного (или обоих) строк так, чтобы они соответствовали, либо добавили в выражение выражение COLLATE.

  • Что это за "сортировка" в любом случае?

    Как описано в Наборы символов и сортировки в целом:

    A набор символов представляет собой набор символов и кодировок. сопоставление - это набор правил для сравнения символов в наборе символов. Позвольте сделать различие понятным на примере мнимого набора символов.

    Предположим, что у нас есть алфавит с четырьмя буквами: "A" , "B" , "A" , "B" . Мы даем каждой букве число: "A" = 0, "B" = 1, "A" = 2, "B" = 3. Буква "A" является символом, число 0 является кодировкой для "A" , а комбинация всех четырех букв и их кодировок - это набор символов .

    Предположим, что мы хотим сравнить два строковых значения: "A" и "B" . Самый простой способ сделать это - посмотреть кодировки: 0 для "A" и 1 для "B" . Поскольку 0 меньше 1, мы говорим: "A" меньше "B" . Мы только что применили сопоставление с нашим набором символов. Сопоставление - это набор правил (только одно правило в этом случае): "сравнить кодировки". Мы называем это простейшее из всех возможных сопоставлений двоичным сопоставлением.

    Но что, если мы хотим сказать, что строчные и прописные буквы эквивалентны? Тогда у нас будет по крайней мере два правила: (1) обрабатывать строчные буквы "A" и "B" как эквивалентные "A" и "B" ; (2), затем сравните кодировки. Мы называем это нечувствительным к регистру сопоставлением. Это немного сложнее, чем двоичная сортировка.

    В реальной жизни большинство наборов символов имеют много символов: не только "A" и "B" , но целые алфавиты, иногда несколько алфавитов или восточные системы письма с тысячами символов, а также множество специальных символов и знаков препинания Метки. Кроме того, в реальной жизни большинство коллайлов имеют много правил, а не только для того, чтобы различать буквенный регистр, но также и для того, чтобы отличить акценты ( "акцент" - это знак, прикрепленный к персонажу, как на немецком языке "Ö" ), и для многосимвольные сопоставления (например, правило "Ö" = "OE" в одном из двух германских сопоставлений).

    Другие примеры приведены в примерах эффекта сортировки.

  • Хорошо, но как MySQL решает, какое сопоставление использовать для данного выражения?

    Как описано в Сочетание выражений:

    В подавляющем большинстве утверждений очевидно, что используется MySQL для сопоставления операции сравнения. Например, в следующих случаях должно быть ясно, что сортировка - это сортировка столбца charset_name:

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

    Однако с несколькими операндами может быть неоднозначность. Например:

    SELECT x FROM T WHERE x = 'Y';

    Если сравнение использует сортировку столбца x или строкового литерала 'Y'? Оба x и 'Y' имеют сопоставления, так что сопоставление имеет приоритет?

    Стандартный SQL разрешает такие вопросы, используя то, что раньше называлось правилами "принуждаемости".

    [ deletia ]

    MySQL использует значения коэрцитивности со следующими правилами для устранения неоднозначностей:

    • Используйте сопоставление с наименьшим значением принуждения.

    • Если обе стороны имеют одну и ту же коэрцитивность, то:

      • Если обе стороны являются Unicode или обе стороны не являются Unicode, это ошибка.

      • Если одна из сторон имеет набор символов Unicode, а другая сторона имеет набор символов, отличных от Юникода, выигрывает сторона с символьным набором Unicode, а автоматическое преобразование набора символов применяется к стороне, отличной от Юникода. Например, следующий оператор не возвращает ошибку:

        SELECT CONCAT(utf8_column, latin1_column) FROM t1;

        Он возвращает результат, имеющий набор символов utf8 и ту же сортировку, что и utf8_column. Значения latin1_column автоматически преобразуются в utf8 перед конкатенацией.

      • Для операции с операндами из того же набора символов, но которые смешивают сортировку _bin и a _ci или _cs, используется сортировка _bin. Это похоже на то, как операции, в которых смешиваются недвоичные и двоичные строки, оценивают операнды как двоичные строки, за исключением того, что они предназначены для сопоставлений, а не для типов данных.

  • Итак, что такое "незаконное сочетание сортировок"?

    "Неправильное сочетание сопоставлений" возникает, когда выражение сравнивает две строки разных сопоставлений, но имеет равную совместимость, а правила принуждения не могут помочь разрешить конфликт. Эта ситуация описана в третьей цитате в приведенной выше цитате.

    Конкретная ошибка, заданная в вопросе Illegal mix of collations (latin1_general_cs,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation '=', говорит нам о том, что было проведено сравнение равенства между двумя строками, не относящимися к Unicode, с равной совместимостью. Кроме того, он говорит нам, что сопоставления не были указаны явно в заявлении, а скорее подразумевались из источников строк (например, метаданных столбца).

  • Все это очень хорошо, но как решить такие ошибки?

    Как показывают приведенные выше выдержки из руководства, эта проблема может быть решена несколькими способами, из которых два являются разумными и рекомендуемыми:

    • Измените сортировку одной (или обеих) строк так, чтобы они совпадали, и больше не существует двусмысленности.

      Как это можно сделать, зависит от того, откуда пришла строка: Литеральные выражения принимают сопоставление, указанное в системной переменной collation_connection; значения из таблиц берут сопоставление, указанное в их метаданных столбцов.

    • Настроить одну строку, чтобы она не была принудительной.

      Я пропустил следующую цитату из вышеперечисленного:

      MySQL присваивает значения коэрцитивности следующим образом:

      • Явное предложение COLLATE обладает способностью к нулю (не является коэрцитивной).

      • Конкатенация двух строк с разными сопоставлениями имеет коэрцитивность 1.

      • Сопоставление столбца или параметра хранимой процедуры или локальной переменной имеет совместимость с 2.

      • "Системная константа" (строка, возвращаемая такими функциями, как USER() или VERSION()) обладает способностью 3.

      • Сопоставление литерала имеет коэрцитивность 4.

      • NULL или выражение, полученное из NULL, имеет коэрцитивность 5.

      Таким образом, просто добавление предложения COLLATE в одну из строк, используемых при сравнении, заставит использовать эту сортировку.

    В то время как другие были бы ужасно плохой практикой, если бы они были развернуты только для устранения этой ошибки:

    • Принудите одну (или обе) строки к некоторым другим значениям коэрцитивности, чтобы иметь преимущество.

      Использование CONCAT() или CONCAT_WS() приведет к тому, что строка с способностью 1; и (если в хранимой процедуре) использование параметров/локальных переменных приведет к строкам с способностью 2.

    • Измените кодировку одной (или обеих) строк так, чтобы она была Unicode, а другая - не.

      Это можно сделать путем перекодирования с помощью CONVERT(expr USING transcoding_name); или путем изменения базового набора символов (например, изменение столбца, изменение character_set_connection для литеральных значений или отправка их с клиента в другую кодировку и изменение character_set_client/добавление средства ввода символов). Обратите внимание, что изменение кодировки приведет к другим проблемам, если некоторые желаемые символы не могут быть закодированы в новом наборе символов.

    • Измените кодировки одной (или обеих) строк так, чтобы они были одинаковыми и изменили одну строку, чтобы использовать соответствующую сортировку _bin.

      Методы изменения кодировок и сопоставлений были подробно описаны выше. Этот подход был бы малопригодным, если бы на самом деле требовалось применять более сложные правила сопоставления, чем предлагалось с помощью сортировки _bin.

Ответ 3

Добавление моего 2c к обсуждению будущих googlers.

Я изучал аналогичную проблему, когда я получил следующую ошибку при использовании пользовательских функций, которые получили параметр varchar:

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

Используя следующий запрос:

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

Я смог сказать, что БД использовала utf8_general_ci, а таблицы были определены с помощью utf8_unicode_ci:

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

Обратите внимание, что представления имеют NULL-сопоставление. Похоже, что представления и функции имеют определения сортировки, хотя этот запрос показывает null для одного представления. Используемая сортировка - это сортировка БД, которая была определена при создании представления/функции.

Печальное решение заключалось в том, чтобы изменить сортировку db и воссоздать представления/функции, чтобы заставить их использовать текущую сортировку.

  • Изменение сортировки db:

    ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;

Надеюсь, это поможет кому-то.

Ответ 4

Иногда бывает сложно конвертировать кодировки, особенно в базы данных с огромным количеством данных. Я думаю, что лучший вариант - использовать "двоичный" оператор:

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

Ответ 5

У меня была аналогичная проблема, я пытался использовать процедуру FIND_IN_SET со строкой переменной.

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

и получал ошибку

Код ошибки: 1267. Недопустимое сочетание сортировок (utf8_unicode_ci, IMPLICIT) и (utf8_general_ci, IMPLICIT) для операции "find_in_set"

Короткий ответ:

Не нужно менять переменные collation_YYYY, просто добавьте правильную сортировку рядом с объявлением переменной, т.е.

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

Длинный ответ:

Сначала я проверил переменные сортировки:

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

Затем я проверил сортировку таблицы:

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;

Это означает, что моя переменная была настроена со значением по умолчанию utf8_general_ci, тогда как моя таблица была настроена как utf8_unicode_ci.

Добавив команду COLLATE рядом с объявлением переменной, сопоставление переменных соответствовало настройке сопоставления для таблицы.

Ответ 6

Вы можете попробовать этот script, который преобразует все ваши базы данных и таблицы в utf8.

Ответ 7

Решение, если речь идет о литералах.

Я использую интеграцию данных Pentaho и не могу указать синтаксис sql. Использование очень простого поиска в БД дало ошибку Msgstr "Недействительное сочетание сортировок (cp850_general_ci, COERCIBLE) и (latin1_swedish_ci, COERCIBLE) для операции '='"

Сгенерированный код был "SELECT DATA_DATE AS last_DATA_DATE FROM hr_cc_normalised_data_date_v WHERE PSEUDO_KEY =?"

Сокращение истории сократило поиск до представления, и когда я выпустил

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  |     |
+------------+------------+-------------------+------+-----+

который объясняет, откуда берется "cp850_general_ci".

Вид был просто создан с помощью 'SELECT' X ',......' В соответствии с такими литералами, как это, следует наследовать их набор символов и сортировку из настроек сервера, которые были правильно определены как "latin1" и "latin1_general_cs", так как этого явно не случилось, я заставил его создать вид

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;

теперь он показывает latin1_general_cs для обоих столбцов, и ошибка исчезла.:)

Ответ 8

MySQL действительно не любит смешивать сортировки, если только он не может принудить их к одному (что явно не возможно в вашем случае). Не можете ли вы просто заставить ту же сортировку использовать предложение COLLATE? (или более простой BINARY ярлык, если применимо...).

Ответ 9

Если столбцы, с которыми у вас возникают проблемы, являются "хэшами", тогда рассмотрим следующее...

Если "хэш" является двоичной строкой, вы действительно должны использовать тип данных BINARY(...).

Если "хеш" - это шестнадцатеричная строка, вам не нужно utf8, и этого следует избегать из-за проверки символов и т.д. Например, MySQL MD5(...) дает 32-байтовую строку с фиксированной длиной. SHA1(...) дает 40-байтовую шестую строку. Это можно сохранить в CHAR(32) CHARACTER SET ascii (или 40 для sha1).

Или, еще лучше, сохраните UNHEX(MD5(...)) в BINARY(16). Это уменьшает половину размера столбца. (Тем не менее, это делает его непечатаемым.) SELECT HEX(hash) ..., если вы хотите, чтобы он был читабельным.

Сравнение двух столбцов BINARY не имеет проблем с сортировкой.

Ответ 11

Другим источником проблемы с сопоставлениями является таблица mysql.proc. Проверьте сортировки ваших процедур хранения и функций:

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

Также обратите внимание на столбцы mysql.proc.collation_connection и mysql.proc.character_set_client.

Ответ 12

Если у вас установлен phpMyAdmin, вы можете следовать инструкциям, приведенным в следующей ссылке: https://mediatemple.net/community/products/dv/204403914/default-mysql-character-set-and-collation Необходимо сопоставить сопоставление базы данных с сопоставлением всех таблиц, а также полей таблиц, а затем перекомпилировать все сохраненные данные. процедуры и функции. С этим все должно работать снова.

Ответ 13

Я использовал ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;, но не работал.

В этом запросе:

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

Эта работа для меня:

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

Да, только concat.

Ответ 14

Этот код необходимо поместить внутри Запустить SQL-запрос/запросы в базе данных

SQL QUERY WINDOW

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

Пожалуйста, замените имя_таблицы и имя_столбца соответствующим именем.