mysql löst zeitzonenbezogene Probleme

Vorwort:

Bei der Verwendung von MySQL können Probleme mit der Zeitzone auftreten, z. B. eine falsche Zeitanzeige, eine Zeitzone, die nicht in der Zone GMT+8 liegt, Inkonsistenzen zwischen der vom Programm abgerufenen Zeit und der in der Datenbank gespeicherten Zeit usw. Tatsächlich hängen diese Probleme alle mit den Zeitzoneneinstellungen der Datenbank zusammen. Dieser Artikel beginnt mit den Datenbankparametern und führt nach und nach zeitzonenbezogene Inhalte ein.

1. Einführung in die log_timestamps-Parameter

Zunächst einmal hat log_timestamps keinen Einfluss auf die Zeitzone, aber unterschiedliche Einstellungen wirken sich auf die Zeit einiger Protokolldatensätze aus. Dieser Parameter steuert hauptsächlich die Anzeigezeit in den Protokolldateien Fehlerprotokoll, langsames Protokoll und allgemeines Protokoll, hat jedoch keinen Einfluss auf die Anzeigezeit des in die Tabelle geschriebenen allgemeinen Protokolls und langsamen Protokolls (mysql.general_log, mysql.slow_log).

log_timestamps ist ein globaler Parameter, der dynamisch geändert werden kann. Standardmäßig wird die UTC-Zeitzone verwendet, wodurch die im Protokoll aufgezeichnete Zeit 8 Stunden langsamer ist als die Peking-Zeit, was die Anzeige des Protokolls unpraktisch macht. Es kann in SYSTEM geändert werden, um die Systemzeitzone zu verwenden. Nachfolgend finden Sie einen einfachen Test der Funktion und Änderungsmethode dieses Parameters:

# Parameterwerte anzeigen mysql> globale Variablen wie ‚log_timestamps‘ anzeigen;
+----------------+--------+
| Variablenname | Wert |
+----------------+--------+
| log_zeitstempel | UTC |
+----------------+--------+
1 Zeile im Satz (0,00 Sek.)

# Langsames logmysql generieren> select sleep(10),now();
+--------------+---------------------+
| schlaf(10) | jetzt() |
+--------------+---------------------+
| 0 | 24.06.2020 17:12:40 |
+--------------+---------------------+
1 Zeile im Satz (10,00 Sek.)

# Die langsame Protokolldatei zeichnet die Erkennungszeit in UTC-Zeit auf. # Zeit: 2020-06-24T09:12:50.555348Z
# Benutzer@Host: root[root] @ localhost [] ID: 10
# Abfragezeit: 10.000354 Sperrzeit: 0.000000 Gesendete Zeilen: 1 Untersuchte Zeilen: 1
SET-Zeitstempel=1592989960;
wähle sleep(10),now();

# Ändern Sie den Parameterwert und testen Sie erneutmysql> set global log_timestamps = SYSTEM;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql> wähle sleep(10),now();
+--------------+---------------------+
| schlaf(10) | jetzt() |
+--------------+---------------------+
| 0 | 24.06.2020 17:13:44 |
+--------------+---------------------+
1 Zeile im Satz (10,00 Sek.)

# Die Zeit des langsamen Protokolldatei-Aufzeichnungsinhalts ist korrekt. # Zeit: 2020-06-24T17:13:54.514413+08:00
# Benutzer@Host: root[root] @ localhost [] ID: 10
# Abfragezeit: 10.000214 Sperrzeit: 0.000000 Gesendete Zeilen: 1 Untersuchte Zeilen: 1
SET-Zeitstempel=1592990024;
wähle sleep(10),now();

2. Einführung in Zeitzonenparameter

Mit dem Parameter time_zone wird die Zeitzone für jede Verbindungssitzung festgelegt. Dieser Parameter ist in globale und Sitzungsebenen unterteilt und kann dynamisch geändert werden. Der Standardwert ist SYSTEM. In diesem Fall wird der Wert des globalen Parameters system_time_zone verwendet. Die system_time_zone wird standardmäßig von der Zeitzone des aktuellen Systems übernommen. Das heißt, die MySQL-Zeitzone ist standardmäßig dieselbe wie die Systemzeitzone.

Die Zeitzoneneinstellung betrifft vorrangig die Anzeige und Speicherung zeitzonensensitiver Zeitwerte. Dies umfasst die von einigen Funktionen angezeigten Werte (wie now() und curtime()) und die im Typ TIMESTAMP gespeicherten Werte. Die Werte in den Spalten DATE, TIME und DATETIME sind davon jedoch nicht betroffen, da diese Datentypen beim Zugriff nicht in die Zeitzone konvertiert werden. Der Typ TIMESTAMP speichert tatsächlich die UTC-Zeit in der Datenbank, und bei der Abfrage werden je nach spezifischer Zeitzone unterschiedliche Zeiten angezeigt.

Als Nächstes testen wir die Auswirkungen einer Änderung des Parameters time_zone:

# Überprüfen Sie die Linux-Systemzeit und Zeitzone [root@centos ~]# date
So, 28. Juni 2020, 14:29:10 CST

# Zeigen Sie die aktuelle Zeitzone und Uhrzeit von MySQLmysql an> show global variables like '%time_zone%';
+------------------+--------+
| Variablenname | Wert |
+------------------+--------+
| Systemzeitzone | CST |
| Zeitzone | SYSTEM |
+------------------+--------+
2 Zeilen im Satz (0,00 Sek.)

mysql> jetzt auswählen();
+---------------------+
| jetzt() |
+---------------------+
| 28.06.2020 14:31:12 |
+---------------------+
1 Zeile im Satz (0,00 Sek.)

# Erstellen Sie eine Testtabelle und fügen Sie einige Daten ein mysql> CREATE TABLE `time_zone_test` (
  -> `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primärschlüssel automatisch inkrementieren',
  -> `dt_col` Datum/Uhrzeit DEFAULT NULL KOMMENTAR 'Datum/Uhrzeit Uhrzeit',
  -> `ts_col` Zeitstempel DEFAULT NULL KOMMENTAR 'Zeitstempel Zeit',
  -> PRIMÄRSCHLÜSSEL (`id`)
  -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Zeitzonen-Testtabelle';
Abfrage OK, 0 Zeilen betroffen, 1 Warnung (0,07 Sek.)

mysql> in time_zone_test (dt_col, ts_col) Werte einfügen ('2020-06-01 17:30:00', '2020-06-01 17:30:00'), (jetzt (), jetzt ());
Abfrage OK, 2 Zeilen betroffen (0,01 Sek.)
Datensätze: 2 Duplikate: 0 Warnungen: 0

mysql> wähle * aus Zeitzonentest;
+----+---------------------+---------------------+
| Ich würde | dt_col | ts_col |
+----+---------------------+---------------------+
| 1 | 01.06.2020 17:30:00 | 01.06.2020 17:30:00 |
| 2 | 28.06.2020 14:34:55 | 28.06.2020 14:34:55 |
+----+---------------------+---------------------+

# Zur UTC-Zeitzone wechseln und erneut verbinden. Es wird festgestellt, dass sich die im Zeitstempel gespeicherte Zeit mit der Zeitzone ändert. mysql> set global time_zone='+0:00';
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
mysql> setze Zeitzone='+0:00';
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql> globale Variablen wie „%time_zone%“ anzeigen;
+------------------+--------+
| Variablenname | Wert |
+------------------+--------+
| Systemzeitzone | CST |
| Zeitzone | +00:00 |
+------------------+--------+
2 Zeilen im Satz (0,00 Sek.)

mysql> jetzt auswählen();
+---------------------+
| jetzt() |
+---------------------+
| 28.06.2020 06:36:16 |
+---------------------+
1 Zeile im Satz (0,00 Sek.)

mysql> wähle * aus Zeitzonentest;
+----+---------------------+---------------------+
| Ich würde | dt_col | ts_col |
+----+---------------------+---------------------+
| 1 | 01.06.2020 17:30:00 | 01.06.2020 09:30:00 |
| 2 | 28.06.2020 14:34:55 | 28.06.2020 06:34:55 |
+----+---------------------+---------------------+
2 Zeilen im Satz (0,00 Sek.)

# Zurück zur Zeitzone East 8 wechseln und zum Normalzustand zurückkehren mysql> set global time_zone='+8:00';
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql> setze Zeitzone='+8:00';
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql> globale Variablen wie „%time_zone%“ anzeigen;
+------------------+--------+
| Variablenname | Wert |
+------------------+--------+
| Systemzeitzone | CST |
| Zeitzone | +08:00 |
+------------------+--------+
2 Zeilen im Satz (0,00 Sek.)

mysql> jetzt auswählen();
+---------------------+
| jetzt() |
+---------------------+
| 28.06.2020 14:39:14 |
+---------------------+
1 Zeile im Satz (0,00 Sek.)

mysql> wähle * aus Zeitzonentest;
+----+---------------------+---------------------+
| Ich würde | dt_col | ts_col |
+----+---------------------+---------------------+
| 1 | 01.06.2020 17:30:00 | 01.06.2020 17:30:00 |
| 2 | 28.06.2020 14:34:55 | 28.06.2020 14:34:55 |
+----+---------------------+---------------------+
2 Zeilen im Satz (0,00 Sek.)

Wenn Sie möchten, dass es dauerhaft ist, müssen Sie es in die Konfigurationsdatei schreiben. Wenn Sie beispielsweise die Zeitzone auf Ost 8 ändern möchten, müssen Sie dem Abschnitt [mysqld] der Konfigurationsdatei eine Zeile hinzufügen: default_time_zone = '+8:00'.

3. Häufige Zeitzonenprobleme und wie man sie vermeidet

Falsche Zeitzoneneinstellungen können verschiedene Probleme verursachen. Hier sind einige häufige Probleme und Lösungen:

3.1 Die interne Zeit von MySQL ist nicht die Peking-Zeit

Wenn Sie auf ein solches Problem stoßen, überprüfen Sie zunächst, ob die Systemzeit und die Zeitzone korrekt sind, und überprüfen Sie dann die Zeitzone von MySQL. Es wird empfohlen, die Zeitzone auf „+8:00“ zu ändern.

3.2 Die vom Java-Programm abgerufene Zeit unterscheidet sich um 8 Stunden von der Zeit in der Datenbank

Dieses Problem wird höchstwahrscheinlich durch die Inkonsistenz zwischen der Zeitzone des Programms und der Zeitzone der Datenbank verursacht. Wir können die Zeitzonen auf beiden Seiten überprüfen. Wenn wir einheitlich die Pekinger Zeit verwenden möchten, können wir serverTimezone=Asia/Shanghai in die JDBC-Verbindungszeichenfolge einfügen und die Zeitzone in MySQL auch auf „+8:00“ ändern.

3.3 Die Programmzeit weicht von der Datenbankzeit um 13 oder 14 Stunden ab

Als ob der Unterschied von 8 Stunden nicht schon überraschend genug wäre, dürfte der Unterschied von 13 Stunden bei vielen Leuten für Verwirrung sorgen. Dieses Problem tritt auf, weil JDBC und MySQL sich bei der Aushandlung der Zeitzone „CST“ nicht einig sind. Da die CST-Zeitzone eine sehr verwirrende Zeitzone ist, hat sie vier Bedeutungen:

• Central Standard Time (USA) UTC-05:00 oder UTC-06:00
• Central Standard Time (Australien) UTC+09:30
• Chinesische Standardzeit UTC+08:00
• Kubanische Standardzeit UTC-04:00
  

Wenn in MySQL „time_zone“ der SYSTEM-Standardwert ist, wird die Zeitzone als Systemzeitzone CST übernommen, die von MySQL intern als UTC+08:00 betrachtet wird. JDBC betrachtet CST als die Central Time der Vereinigten Staaten, was zu einem Unterschied von 13 Stunden führt. Wenn es Winterzeit ist, beträgt der Unterschied 14 Stunden.

Die Lösung für dieses Problem ist ebenfalls sehr einfach. Wir können die Zeitzone der MySQL-Datenbank explizit angeben. Anstatt die irreführende CST zu verwenden, können wir time_zone in „+8:00“ ändern und serverTimezone=Asia/Shanghai zur JDBC-Verbindungszeichenfolge hinzufügen.

3.4 So vermeiden Sie Zeitzonenprobleme

Möglicherweise haben Sie einige Ideen, wie Sie die oben genannten Zeitzonenprobleme vermeiden können. Hier sind einige kurze Zusammenfassungen:

1. Stellen Sie zunächst sicher, dass die Zeitzone des Systems korrekt ist.
2. Die Zeitzone wird in der JDBC-Verbindungszeichenfolge angegeben und entspricht der Zeitzone der Datenbank.
3. Die empfohlene Einstellung für den Zeitzonenparameter ist „+8:00“, um die Verwendung von CST zu vermeiden, die leicht irreführend ist.
4. Die Zeitzonenparameter der Datenbankinstanzen bleiben in jeder Umgebung gleich.
   

Einige Studenten haben möglicherweise gesagt, dass der Zeitzonenparameter in unserer Datenbank den Standardsystemwert auswählt und es keine Inkonsistenz zwischen der Programmzeit und der Datenbankzeit gibt. Muss ich die Zeitzone jetzt auf „+8:00“ ändern? In diesem Fall wird empfohlen, time_zone auf „+8:00“ zu ändern, insbesondere wenn das Feld TIMESTAMP häufig abgefragt wird. Denn wenn time_zone=system ist, wird bei der Abfrage des Felds timestamp die Systemzeitzone zur Zeitzonenkonvertierung aufgerufen, die durch die globale Sperre __libc_lock_lock geschützt ist, was die Systemleistung in einer Thread-Parallelitätsumgebung einschränken kann. Wenn Sie es auf „+8:00“ ändern, wird die Zeitzonenkonvertierung des Systems nicht ausgelöst und es wird die eigene Konvertierung von MySQL verwendet, was die Leistung erheblich verbessert.

Zusammenfassen:

Haben Sie nach dem Lesen dieses Artikels ein tieferes Verständnis der Zeitzone von Datenbanken? Ich hoffe, dieser Artikel ist hilfreich für Sie, insbesondere wenn Sie mehr über MySQL-Zeitzonen erfahren möchten. Wenn bei Ihnen andere zeitzonenbezogene Probleme aufgetreten sind, hinterlassen Sie bitte eine Nachricht, um diese zu besprechen.

Oben finden Sie Einzelheiten dazu, wie MySQL zeitzonenbezogene Probleme löst. Weitere Informationen zu zeitzonenbezogenen Problemen mit MySQL finden Sie in den anderen entsprechenden Artikeln auf 123WORDPRESS.COM!