emoji - thinkphp mysql Wie kann ich die angegebene Tabelle mit der angegebenen Zeichenkodierung abfragen und bedienen?

Das Problem ist folgendes:
Es gibt eine Datenbank mit vielen Tabellen und vielen vorhandenen Daten. Die meisten dieser Daten sind in utf8 gespeichert (nicht alle, es gibt auch latin1).
Wir sind auf ein Problem gestoßen, bei dem Benutzer Emojis nicht speichern konnten. Es ist bekannt, dass utf8mb4 für die korrekte Speicherung erforderlich ist.

Mysql wurde von 5.1 auf 5.6.26 aktualisiert. Nächste Gedanken und bestehende Versuche:
1. Wenn die gesamte Datenbank auf uft8mb4 aktualisiert wird, ist das Risiko zu groß, da die verschiedenen Aufrufstellen chaotisch und schlecht gewartet werden. Wenn sie direkt auf utf8mb4 geändert wird, ist das gesamte System möglicherweise nicht möglich normal sein.

2. Erwägen Sie, nur die Tabelle, in der Benutzer Emojis speichern (im Folgenden als Tabelle E bezeichnet), auf uft8mb4 zu aktualisieren, und die Codierungseinstellungen werden in config abgelegt. Wenn Sie dies ändern, wird thinkphp vollständig zerstört.

3. Wenn wir 2 betrachten, verwendet der Hauptteil von thinkphp weiterhin uft8 unverändert und nur vorübergehend uft8mb4, wenn diese Tabelle E abgefragt wird. Versuchen Sie M()->query('SET NAMES 'utf8mb4''); und erhalten Sie die Fehlermeldung: SQLSTATE[HY000]: General error

4. Ich denke immer noch über Methode 2 nach, aber sie funktioniert nicht. Denn auch nach erfolgreicher Abfrage dieser Tabelle E werden Vorgänge für andere Tabellen ausgeführt und uft8mb4 kann bei der nachfolgenden Abfrage Fehler verursachen.

Gibt es eine gute Möglichkeit, Vorgänge, die utf8mb4 kodieren, nur für diese Tabelle auszuführen, ohne die Vorgänge anderer Tabellen zu beeinträchtigen?

PS: Da die Produktionsumgebung seit einem Jahr online ist und über viele Daten und Online-Benutzer verfügt, wurde dieses Problem erst jetzt in Tests gemeldet. Es ist zu riskant, die Codierung der gesamten Datenbank zu aktualisieren. Die Idee des Leiters besteht darin, zuerst die Fallstricke zu beseitigen und so zu tun, als würde er die nicht entdeckten Fallstricke nicht erkennen.
Glücklicherweise habe ich beim Aufbau des Systems die Produktionsumgebung installiert und MySQL war zu Beginn die neueste Version 5.6.26. Ich hoffe, dass die Methode der Neucodierung von Emojis nur als letzte Lösung eingesetzt wird.

Antwortinhalt:

Das Problem ist folgendes:
Es gibt eine Datenbank mit vielen Tabellen und vielen vorhandenen Daten. Die meisten dieser Daten sind in utf8 gespeichert (nicht alle, es gibt auch latin1).
Wir sind auf ein Problem gestoßen, bei dem Benutzer Emojis nicht speichern konnten. Es ist bekannt, dass utf8mb4 für die korrekte Speicherung erforderlich ist.

Mysql wurde von 5.1 auf 5.6.26 aktualisiert. Nächste Gedanken und bestehende Versuche:
1. Wenn die gesamte Datenbank auf uft8mb4 aktualisiert wird, ist das Risiko zu groß, da die verschiedenen Aufrufstellen chaotisch und schlecht gewartet werden. Wenn sie direkt auf utf8mb4 geändert wird, ist das gesamte System möglicherweise nicht möglich normal sein.

2. Erwägen Sie, nur die Tabelle, in der Benutzer Emojis speichern (im Folgenden als Tabelle E bezeichnet), auf uft8mb4 zu aktualisieren, und die Codierungseinstellungen werden in config abgelegt. Wenn Sie dies ändern, wird thinkphp vollständig zerstört.

3. Wenn wir 2 betrachten, verwendet der Hauptteil von thinkphp immer noch uft8 und verwendet uft8mb4 nur vorübergehend, wenn diese Tabelle E abgefragt wird. Versuchen Sie M()->query('SET NAMES 'utf8mb4''); und erhalten Sie die Fehlermeldung: SQLSTATE[HY000]: General error

4. Ich denke immer noch über Methode 2 nach, aber sie funktioniert nicht. Denn auch nach erfolgreicher Abfrage dieser Tabelle E werden Vorgänge für andere Tabellen ausgeführt und uft8mb4 kann bei der nachfolgenden Abfrage Fehler verursachen.

Gibt es eine gute Möglichkeit, Vorgänge, die utf8mb4 kodieren, nur für diese Tabelle auszuführen, ohne die Vorgänge anderer Tabellen zu beeinträchtigen?

PS: Da die Produktionsumgebung seit einem Jahr online ist und über viele Daten und Online-Benutzer verfügt, wurde dieses Problem erst jetzt in Tests gemeldet. Es ist zu riskant, die Codierung der gesamten Datenbank zu aktualisieren. Die Idee des Leiters besteht darin, zuerst die Fallstricke zu beseitigen und so zu tun, als würde er die nicht entdeckten Fallstricke nicht erkennen.
Glücklicherweise habe ich beim Aufbau des Systems die Produktionsumgebung installiert und MySQL war zu Beginn die neueste Version 5.6.26. Ich hoffe, dass die Methode der Neucodierung von Emojis nur als letzte Lösung eingesetzt wird.