Fehlerbehebung beim Fehler "Unzulässige Mischung von Kollatierungen" in MySQL

210

Beim Versuch, eine Auswahl über eine in MySQL gespeicherte Prozedur durchzuführen, wird der folgende Fehler angezeigt.

Unzulässige Mischung von Kollatierungen (latin1_general_cs, IMPLICIT) und (latin1_general_ci, IMPLICIT) für die Operation '='

Irgendeine Idee, was hier falsch laufen könnte?

Die Sortierung der Tabelle ist latin1_general_ciund die der Spalte in der where-Klausel latin1_general_cs.

user355562
quelle
2
Ich habe eine Vielzahl von Datenbanken für einen großen Zeitraum (seit 1990) verwendet, und die Verwendung von Kollatierung und Zwang durch NySQL erscheint als "verrückt". Datenbanken lösen Probleme, die "EINEN" Zeichensatz für die Datenbank auferlegen, und sind dann bis zu die Import / Export-Prozeduren zum Konvertieren von / in den von der Datenbank verwendeten eindeutigen Zeichensatz. Die von MySQL ausgewählten Lösungen sind störend, da "Anwendungsprobleme" (Zeichensatzkonvertierung) mit Datenbankproblemen (Verwendung der Sortierung) gemischt werden. Warum nicht diese albernen und umständlichen Funktionen aus der Datenbank "entfernen", damit sie von a
Maurizio Pievaioli am

Antworten:

216

Dies wird im Allgemeinen durch den Vergleich zweier Zeichenfolgen inkompatibler Kollatierung oder durch den Versuch verursacht, Daten unterschiedlicher Kollatierung in einer kombinierten Spalte auszuwählen.

Mit dieser Klausel COLLATEkönnen Sie die in der Abfrage verwendete Sortierung angeben.

Beispielsweise gibt die folgende WHEREKlausel immer den Fehler aus, den Sie gepostet haben:

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

Ihre Lösung besteht darin, eine gemeinsame Sortierung für die beiden Spalten in der Abfrage anzugeben. Hier ist ein Beispiel, das die COLLATEKlausel verwendet:

SELECT * FROM table ORDER BY key COLLATE latin1_general_ci;

Eine andere Option ist die Verwendung des BINARYOperators:

BINARY str ist die Abkürzung für CAST (str AS BINARY).

Ihre Lösung könnte ungefähr so ​​aussehen:

SELECT * FROM table WHERE BINARY a = BINARY b;

oder,

SELECT * FROM table ORDER BY BINARY a;
definiert
quelle
2
Vielen Dank. Eigentlich scheint es sich in meinem Fall ziemlich komisch zu verhalten. Wenn ich die Abfrage so ausführe, wie sie ist, werden über den Abfragebrowser die Ergebnisse abgerufen. Die Verwendung einer gespeicherten Prozedur führt jedoch zu einem Fehler.
user355562
5
Binär schien die beste Lösung für mich zu sein. Es ist möglicherweise auch das Beste für Sie, wenn Sie keine kniffligen Filter verwenden.
Adam F
Ich habe das gleiche Problem, die Art und Weise, wie ich dieses Problem löse, wird von Anfang an neu erstellt. Ich habe versucht, die Sortierung zu ändern, aber als ich beitrete, ist immer noch ein Fehler aufgetreten, also habe ich es auf diese Weise versucht. cmiiw
Bobby Z
Bitte beachten Sie, dass es in MariaDB COLLATE latin1_general_ci einen Fehler gibt, der einen weiteren Fehler verursacht: COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'latin1''- Auch wenn Sie keine Spalte mit CHARACTER SET 'latin1' haben! Die Lösung besteht darin, die BINARY-Besetzung zu verwenden. Siehe auch diese Frage
Mel_T
154

TL; DR

Ändern Sie entweder die Sortierung einer (oder beider) Zeichenfolgen so, dass sie übereinstimmen, oder fügen Sie COLLATEIhrem Ausdruck eine Klausel hinzu.


  1. Was ist das für eine "Zusammenstellung"?

    Wie unter Zeichensätze und Kollatierungen im Allgemeinen dokumentiert :

    EIN Zeichensatz ist ein Satz von Symbolen und Codierungen. Eine Sortierung ist ein Satz von Regeln zum Vergleichen von Zeichen in einem Zeichensatz. Lassen Sie uns die Unterscheidung anhand eines Beispiels eines imaginären Zeichensatzes verdeutlichen.

    Angenommen, wir haben ein Alphabet mit vier Buchstaben: " A", " B", " a", " b". Wir geben jedem Buchstaben eine Zahl: " A" = 0, " B" = 1, " a" = 2, " b" = 3. Der Buchstabe " A" ist ein Symbol, die Zahl 0 ist die Kodierung für " A" und die Kombination aller vier Buchstaben und ihre Kodierungen ist ein Zeichensatz .

    Angenommen, wir möchten zwei Zeichenfolgenwerte vergleichen, " A" und " B". Der einfachste Weg, dies zu tun, besteht darin, sich die Codierungen anzusehen: 0 für " A" und 1 für "B ". Da 0 kleiner als 1 ist, sagen wir, dass " A" kleiner als " B" ist. Was wir gerade getan haben, ist eine Kollation auf unseren Zeichensatz anzuwenden. Die Sortierung besteht aus einer Reihe von Regeln (in diesem Fall nur eine Regel): "Vergleichen Sie die Codierungen." Wir nennen diese einfachste aller möglichen Kollatierungen eine binäre Kollatierung.

    Aber was ist, wenn wir sagen wollen, dass Klein- und Großbuchstaben gleichwertig sind? Dann hätten wir mindestens zwei Regeln: (1) Behandle die Kleinbuchstaben " a" und " b" als äquivalent zu " A" und " B"; (2) Vergleichen Sie dann die Codierungen. Wir nennen dies eine Kollatierung ohne Berücksichtigung der Groß- und Kleinschreibung . Es ist etwas komplexer als eine binäre Zusammenstellung.

    Im wirklichen Leben haben die meisten Zeichensätze viele Zeichen: nicht nur " A" und " B", sondern ganze Alphabete, manchmal mehrere Alphabete oder östliche Schriftsysteme mit Tausenden von Zeichen, zusammen mit vielen speziellen Symbolen und Satzzeichen. Auch im wirklichen Leben haben die meisten Kollatierungen viele Regeln, nicht nur für die Unterscheidung von Groß- und Kleinschreibung, sondern auch für die Unterscheidung von Akzenten (ein „Akzent“ ist eine Markierung, die einem Zeichen wie auf Deutsch zugeordnet ist).Ö “ zugeordnet ist) und für mehrere Zeichen Zuordnungen (wie die Regel, dass " Ö" = " OE" in einer der beiden deutschen Kollatierungen).

    Weitere Beispiele finden Sie unter Beispiele für den Effekt der Kollatierung .

  2. Okay, aber wie entscheidet MySQL, welche Sortierung für einen bestimmten Ausdruck verwendet werden soll?

    Wie unter Zusammenstellung von Ausdrücken dokumentiert :

    In der überwiegenden Mehrheit der Aussagen ist es offensichtlich, welche Kollatierung MySQL verwendet, um eine Vergleichsoperation aufzulösen. In den folgenden Fällen sollte beispielsweise klar sein, dass die Kollatierung die Kollatierung der Spalte ist charset_name:

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

    Bei mehreren Operanden kann es jedoch zu Mehrdeutigkeiten kommen. Beispielsweise:

    SELECT x FROM T WHERE x = 'Y';

    Sollte der Vergleich die Sortierung der Spalte xoder des Zeichenfolgenliteral verwenden 'Y'? Beide xund 'Y'haben Kollatierungen. Welche Kollatierung hat also Vorrang?

    Standard SQL löst solche Fragen mit den sogenannten "Zwangsregeln".

    [ Deletia ]

    MySQL verwendet Zwangswerte mit den folgenden Regeln, um Mehrdeutigkeiten aufzulösen:

    • Verwenden Sie die Sortierung mit dem niedrigsten Koerzitivfeldwert.

    • Wenn beide Seiten die gleiche Zwanghaftigkeit haben, dann:

      • Wenn beide Seiten Unicode sind oder beide Seiten nicht Unicode sind, liegt ein Fehler vor.

      • Wenn eine der Seiten einen Unicode-Zeichensatz und eine andere Seite einen Nicht-Unicode-Zeichensatz hat, gewinnt die Seite mit dem Unicode-Zeichensatz, und die automatische Zeichensatzkonvertierung wird auf die Nicht-Unicode-Seite angewendet. Die folgende Anweisung gibt beispielsweise keinen Fehler zurück:

        SELECT CONCAT(utf8_column, latin1_column) FROM t1;

        Es wird ein Ergebnis zurückgegeben, das einen Zeichensatz utf8und dieselbe Sortierung wie hat utf8_column. Werte von latin1_columnwerden utf8vor der Verkettung automatisch in konvertiert .

      • Für eine Operation mit Operanden aus demselben Zeichensatz, die jedoch eine _binKollatierung und eine _cioder _csKollatierung mischen , wird die _binKollatierung verwendet. Dies ähnelt der Art und Weise, wie Operationen, die nicht-binäre und binäre Zeichenfolgen mischen, die Operanden als binäre Zeichenfolgen auswerten, mit der Ausnahme, dass sie eher für Kollatierungen als für Datentypen gelten.

  3. Was ist also eine "illegale Mischung von Kollatierungen"?

    Eine "illegale Mischung von Kollatierungen" tritt auf, wenn ein Ausdruck zwei Zeichenfolgen unterschiedlicher Kollatierungen, aber gleicher Zwangsfähigkeit vergleicht und die Zwangsregeln nicht zur Lösung des Konflikts beitragen können. Dies ist die Situation, die unter dem dritten Punkt im obigen Zitat beschrieben ist.

    Der in der Frage angegebene besondere Fehler zeigt Illegal mix of collations (latin1_general_cs,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation '=', dass es einen Gleichheitsvergleich zwischen zwei Nicht-Unicode-Zeichenfolgen mit gleicher Zwangsfähigkeit gab. Außerdem erfahren wir, dass die Kollatierungen nicht explizit in der Anweisung angegeben wurden, sondern aus den Quellen der Zeichenfolgen (z. B. Spaltenmetadaten) stammen.

  4. Das ist alles sehr gut, aber wie löst man solche Fehler?

    Wie aus den oben zitierten manuellen Auszügen hervorgeht, kann dieses Problem auf verschiedene Weise gelöst werden, von denen zwei sinnvoll und zu empfehlen sind:

    • Ändern Sie die Sortierung einer (oder beider) Zeichenfolgen so, dass sie übereinstimmen und keine Mehrdeutigkeit mehr besteht.

      Wie dies getan werden kann, hängt davon ab, woher die Zeichenfolge stammt: Literale Ausdrücke verwenden die in der collation_connectionSystemvariablen angegebene Kollatierung. Werte aus Tabellen verwenden die in ihren Spaltenmetadaten angegebene Sortierung.

    • Erzwinge, dass eine Saite nicht erzwungen werden kann.

      Ich habe das folgende Zitat oben weggelassen:

      MySQL weist die Coercibility-Werte wie folgt zu:

      • Eine explizite COLLATEKlausel hat eine Zwangsfähigkeit von 0. (Überhaupt nicht zwingbar.)

      • Die Verkettung von zwei Strings mit unterschiedlichen Kollatierungen hat eine Koerzitivfeldstärke von 1.

      • Die Sortierung einer Spalte oder eines gespeicherten Routineparameters oder einer lokalen Variablen hat eine Koerzitivkraft von 2.

      • Eine "Systemkonstante" (die Zeichenfolge, die von Funktionen wie USER()oder zurückgegeben wird VERSION()) hat eine Koerzitivfeldstärke von 3.

      • Die Zusammenstellung eines Literals hat eine Koerzitivkraft von 4.

      • NULLoder ein Ausdruck, der von abgeleitet ist, NULLhat eine Zwangsfähigkeit von 5.

      Durch einfaches Hinzufügen einer COLLATEKlausel zu einer der im Vergleich verwendeten Zeichenfolgen wird die Verwendung dieser Kollatierung erzwungen.

    Während die anderen eine schrecklich schlechte Praxis wären, wenn sie nur zur Behebung dieses Fehlers eingesetzt würden:

    • Erzwingen Sie, dass eine (oder beide) der Zeichenfolgen einen anderen Koerzitivfeldwert haben, damit einer Vorrang hat.

      Die Verwendung von CONCAT()oder CONCAT_WS()würde zu einer Zeichenfolge mit einer Zwangsfähigkeit von 1 führen; und (wenn in einer gespeicherten Routine) die Verwendung von Parametern / lokalen Variablen würde zu Zeichenfolgen mit einer Zwangsfähigkeit von 2 führen.

    • Ändern Sie die Codierungen einer (oder beider) Zeichenfolgen so, dass eine Unicode ist und die andere nicht.

      Dies könnte durch Transcodieren mit erfolgen ; oder durch Ändern des zugrunde liegenden Zeichensatzes der Daten (z. B. Ändern der Spalte, Ändern von Literalwerten oder Senden dieser vom Client in einer anderen Codierung und Ändern / Hinzufügen eines Zeichensatz-Einführers). Beachten Sie, dass das Ändern der Codierung zu anderen Problemen führt, wenn einige gewünschte Zeichen im neuen Zeichensatz nicht codiert werden können.CONVERT(expr USING transcoding_name)character_set_connectioncharacter_set_client

    • Ändern Sie die Codierungen einer (oder beider) Zeichenfolgen so, dass beide gleich sind, und ändern Sie eine Zeichenfolge, um die entsprechende _binSortierung zu verwenden.

      Verfahren zum Ändern von Codierungen und Kollatierungen wurden oben detailliert beschrieben. Dieser Ansatz wäre wenig nützlich, wenn tatsächlich fortgeschrittenere Kollatierungsregeln angewendet werden müssten, als die _binKollatierung bietet .

eggyal
quelle
4
Beachten Sie, dass eine "illegale Mischung von Kollatierungen" auch dann auftreten kann, wenn keine Unklarheit darüber besteht, welche Kollatierung verwendet werden soll, die zu erzwingende Zeichenfolge jedoch in eine Codierung transkodiert werden muss, in der einige ihrer Zeichen nicht dargestellt werden können. Ich habe diesen Fall in einer früheren Antwort besprochen .
Eggyal
5
Gute Antwort. Dieser sollte weiter oben sein, da er sich mit dem befasst, was Entwickler wirklich wissen sollten. nicht nur, wie man es behebt, sondern wirklich versteht, warum die Dinge so geschehen, wie sie geschehen.
Markieren Sie den
Danke Alter, du hast mir heute etwas beigebracht.
Briankip
66

Hinzufügen meiner 2c zur Diskussion für zukünftige Googler.

Ich habe ein ähnliches Problem untersucht, bei dem bei Verwendung benutzerdefinierter Funktionen , die einen varchar-Parameter erhalten haben, der folgende Fehler aufgetreten ist:

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

Verwenden Sie die folgende Abfrage:

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

Ich konnte feststellen, dass die Datenbank utf8_general_ci verwendet , während die Tabellen mit utf8_unicode_ci definiert wurden :

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

Beachten Sie, dass die Ansichten eine NULL- Sortierung haben. Es scheint, dass Ansichten und Funktionen Kollatierungsdefinitionen haben, obwohl diese Abfrage für eine Ansicht null anzeigt. Die verwendete Kollatierung ist die DB-Kollatierung, die beim Erstellen der Ansicht / Funktion definiert wurde.

Die traurige Lösung bestand darin, sowohl die Datenbankkollatierung zu ändern als auch die Ansichten / Funktionen neu zu erstellen, um sie zu zwingen, die aktuelle Kollatierung zu verwenden.

  • Ändern der Kollatierung der Datenbank:

    ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci;
  • Ändern der Tabellensortierung:

    ALTER TABLE mydb CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Ich hoffe das wird jemandem helfen.

Ariel T.
quelle
12
Die Sortierung kann auch auf Spaltenebene festgelegt werden. Sie können es anzeigen mit:show full columns from my_table;
Jonathan Tran
Danke dir. Ich habe gerade das Schema gelöscht, es mit der richtigen Standardkollatierung neu erstellt und alles neu importiert.
JRun
1
@ JonathanTran Danke! Ich hatte den Zeichensatz und die Sortierung für alle Tabellen, die Datenbank und die Verbindung festgelegt, aber es gab immer noch einen Fehler! Die Sortierung wurde nicht auf eine Spalte gesetzt! Ich habe es behoben mitalter table <TABLE> modify column <COL> varchar(255) collate utf8_general_ci;
Chloe
2
Nebenbemerkung für zukünftige Googler: Auch wenn Ihre Datenbank, Tabellen und Felder dieselbe Sortierung haben, müssen Sie sicherstellen, dass Ihre Verbindung dieselbe Sortierung verwendet. Alles hat »utf8mb4_unicode_ci«, SHOW session variables like '%collation%';sagt aber , dass »collation_connection« »utf8mb4_general_ci« ist? Dann SET collation_connection = utf8mb4_unicode_civorher laufen .
Pixelbrackets
Danke dir! Ich habe eine Weile gebraucht, um das aufzuspüren. Die Tabellen müssen nicht nur dieselbe Sortierung haben, sondern auch die DB!
Moto
15

Manchmal kann es gefährlich sein, Zeichensätze zu konvertieren, insbesondere in Datenbanken mit großen Datenmengen. Ich denke, die beste Option ist die Verwendung des "binären" Operators:

e.g : WHERE binary table1.column1 = binary table2.column1
Justin Vincent
quelle
10

Ich hatte ein ähnliches Problem, wurde versucht , die FIND_IN_SET Prozedur mit einer Zeichenfolge zu verwenden Variable .

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

und erhielt den Fehler

Fehlercode: 1267. Unzulässige Mischung von Kollatierungen (utf8_unicode_ci, IMPLICIT) und (utf8_general_ci, IMPLICIT) für die Operation 'find_in_set'

Kurze Antwort:

Sie müssen keine Variablen collation_YYYY ändern. Fügen Sie einfach die richtige Kollatierung neben Ihrer Variablendeklaration hinzu , d. H.

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

Lange Antwort:

Ich habe zuerst die Kollatierungsvariablen überprüft:

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

Dann habe ich die Tabellensortierung überprüft:

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;

Dies bedeutet, dass meine Variable mit der Standardkollatierung von utf8_general_ci konfiguriert wurde, während meine Tabelle als utf8_unicode_ci konfiguriert wurde .

Durch Hinzufügen des Befehls COLLATE neben der Variablendeklaration stimmte die Variablenkollatierung mit der für die Tabelle konfigurierten Kollatierung überein.

nkatsar
quelle
5

Sie können dieses Skript ausprobieren , das alle Ihre Datenbanken und Tabellen in utf8 konvertiert.

Mirat Can Bayrak
quelle
1
Zeile 24 "cur" statt "cursor"
RTOSkit
2
Und verdreifacht die Größe einiger Indizes.
Damian Yerrick
2

Lösung, wenn Literale beteiligt sind.

Ich verwende Pentaho Data Integration und kann die SQL-Syntax nicht angeben. Die Verwendung einer sehr einfachen DB-Suche ergab den Fehler "Unzulässige Mischung von Kollatierungen (cp850_general_ci, COERCIBLE) und (latin1_swedish_ci, COERCIBLE) für die Operation '='".

Der generierte Code war "SELECT DATA_DATE AS latest_DATA_DATE FROM hr_cc_normalised_data_date_v WHERE PSEUDO_KEY =?"

Um die Geschichte kurz zu fassen, war die Suche nach einer Ansicht und als ich herausgab

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

das erklärt, woher das 'cp850_general_ci' kommt.

Die Ansicht wurde einfach mit 'SELECT' X 'erstellt, ......' Laut den manuellen Literalen sollten solche ihren Zeichensatz und ihre Sortierung von Servereinstellungen erben, die korrekt als 'latin1' und 'latin1_general_cs' definiert wurden Offensichtlich ist es nicht passiert. Ich habe es bei der Erstellung der Ansicht erzwungen

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;

Jetzt wird latin1_general_cs für beide Spalten angezeigt und der Fehler ist behoben. :) :)

jc508
quelle
1

MySQL mag es wirklich nicht, Kollatierungen zu mischen, es sei denn, es kann sie zu derselben zwingen (was in Ihrem Fall eindeutig nicht möglich ist). Können Sie nicht einfach die Verwendung derselben Kollatierung über eine COLLATE-Klausel erzwingen ? (oder die einfachere BINARYVerknüpfung, falls zutreffend ...).

Alex Martelli
quelle
Ist das einzigartig für MySQL? Wie gehen andere Systeme mit einer Mischung inkompatibler Kollatierungen von scheinbar gleicher Priorität um?
Eggyal
Ihr Link ist ungültig.
Benubird
1

Wenn die Spalten, mit denen Sie Probleme haben, "Hashes" sind, beachten Sie Folgendes ...

Wenn der "Hash" eine binäre Zeichenfolge ist, sollten Sie wirklich den BINARY(...)Datentyp verwenden.

Wenn der "Hash" eine Hex-Zeichenfolge ist, benötigen Sie utf8 nicht und sollten dies aufgrund von Zeichenprüfungen usw. vermeiden. Beispielsweise MD5(...)liefert MySQL eine Hex-Zeichenfolge mit fester Länge von 32 Byte. SHA1(...)gibt eine 40-Byte-Hex-Zeichenfolge. Dies könnte in CHAR(32) CHARACTER SET ascii(oder 40 für sha1) gespeichert werden .

Oder, noch besser, speichert UNHEX(MD5(...))in BINARY(16). Dies halbiert die Größe der Säule. (Es macht es jedoch ziemlich unbedruckbar.) SELECT HEX(hash) ...Wenn Sie möchten, dass es lesbar ist.

Beim Vergleichen von zwei BINARYSpalten treten keine Sortierprobleme auf.

Rick James
quelle
1

Sehr interessant ... Jetzt sei bereit. Ich habe mir alle "Add Collate" -Lösungen angesehen und für mich sind dies Pflasterkorrekturen. Die Realität ist, dass das Datenbankdesign "schlecht" war. Ja, Standardänderungen und neue Dinge werden hinzugefügt, bla bla, aber es ändert nichts an der Tatsache, dass das Datenbankdesign schlecht ist. Ich lehne es ab, alle SQL-Anweisungen mit "sortieren" zu versehen, damit meine Abfrage funktioniert. Die einzige Lösung, die für mich funktioniert und die Notwendigkeit, meinen Code in Zukunft zu optimieren, praktisch überflüssig macht, besteht darin, die Datenbank / Tabellen so zu gestalten, dass sie dem Zeichensatz entsprechen, mit dem ich leben und den ich langfristig annehmen werde. In diesem Fall entscheide ich mich für den Zeichensatz " utf8mb4 ".

Die Lösung hier, wenn Sie auf diese "illegale" Fehlermeldung stoßen, besteht darin, Ihre Datenbank und Tabellen neu zu gestalten. Es ist viel einfacher und schneller als es sich anhört. Das Exportieren und erneute Importieren Ihrer Daten aus einer CSV ist möglicherweise nicht einmal erforderlich. Ändern Sie den Zeichensatz der Datenbank und stellen Sie sicher, dass alle Zeichensätze Ihrer Tabellen übereinstimmen.

Verwenden Sie diese Befehle, um Sie zu führen:

SHOW VARIABLES LIKE "collation_database";
SHOW TABLE STATUS;

Wenn Sie es genießen, hier und da "zusammenstellen" hinzuzufügen und Ihren Code mit erzwungenen "Überschreibungen" zu verstärken, sollten Sie raten.

Nya Nguyen
quelle
0

Eine weitere Ursache für das Problem mit Kollatierungen ist die mysql.procTabelle. Überprüfen Sie die Zusammenstellungen Ihrer Speicherverfahren und -funktionen:

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

Achten Sie auch auf mysql.proc.collation_connectionund mysql.proc.character_set_clientSpalten.

Ruvim
quelle
-1

ich benutzte ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci; , aber nicht funktioniert.

In dieser Abfrage:

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

Diese Arbeit für mich:

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

Ja, nur a concat.

Knito Auron
quelle
Überprüfen Sie die Sortierung Ihrer Tabellen und ihrer Spalten (zeigen Sie den Tabellenstatus an und zeigen Sie die vollständigen Spalten aus Tabelle1 an;). Die Verwendung der Datenbank alter würde nicht funktionieren, wenn die Tabellen bereits mit der falschen Sortierung erstellt wurden.
Ariel T
ALTER DATABASE mydb DEFAULT COLLATE ... hat für mich gearbeitet, also stimme zu. Vielleicht hatte ich einen Vorteil, da ich die Datenbank löschen und neu erstellen und aus Backups laden konnte.
Tobixen
-2

Dieser Code muss in Run SQL Query / Queries on Database eingefügt werden

SQL QUERY WINDOW

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

Bitte ersetzen Sie Tabellenname und Spaltenname durch den entsprechenden Namen.

Sukumar
quelle