изменение сопоставления самой информационной_схемы [дубликат]

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

Возможным решением является преобразовать всю базу данных в UTF8 (см. также этот вопрос ).

Этот код необходимо поместить внутри Запустить 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;

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

Решение, если используются литералы.

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

Сгенерированный код был« SELECT DATA_DATE AS latest_DATA_DATE FROM hr_cc_normalised_data_date_v ГДЕ 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 для обоих столбцов, и ошибка исчезла. :)

Я использовал 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.

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

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

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

У меня была аналогичная проблема, я пытался использовать процедуру 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 next к объявлению переменной, сопоставление переменных соответствует настройке, настроенной для таблицы.

Добавление моего 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;
  

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

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

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

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

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

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

Другим источником проблемы с сопоставлениями является таблица 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.

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

В предложении 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 (str AS BINARY).

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

SELECT * FROM table WHERE BINARY a = BINARY b;

или,

SELECT * FROM table ORDER BY BINARY a;