Warum kann MySQL bei der Verwendung von Zeitstempeln Zeitzonenprobleme ignorieren?

Warum kann MySQL bei der Verwendung von Zeitstempeln Zeitzonenprobleme ignorieren?

Ich habe mich immer gefragt, warum der timestamp MySQL Datenbank das Zeitzonenproblem ignorieren kann.
Ich verwende in meinem Unternehmen das Laravel -Framework und die integrierte Migration verwendet auch Felder vom Typ timestamp , daher ist mir das nicht so wichtig.

Start

Anzeigen der aktuellen Datenbank-Zeitzone

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

Tabellenstruktur anzeigen

mysql> Beschreibung Zeitstempel_Test;
+--------------+--------------+------+-----+---------+----------------+
| Feld | Typ | Null | Schlüssel | Standard | Extra |
+--------------+--------------+------+-----+---------+----------------+
| ID | int | NEIN | PRI | NULL | auto_increment |
| Erstellungszeit | Datum/Uhrzeit | JA | | NULL | |
| erstellt am | Zeitstempel | JA | | NULL | |
+--------------+--------------+------+-----+---------+----------------+
3 Reihen im Satz (0,26 Sek.)

Einfügen von Daten

mysql> einfügen in timestamp_test(erstellt_zeit, erstellt_am) Werte('2020-12-09 08:00:00', '2020-12-09 08:00:00');
Abfrage OK, 1 Zeile betroffen (0,22 Sek.)


mysql> wähle * aus Zeitstempel_test;
+----+---------------------+---------------------+
| ID | Erstellungszeit | Erstellungsdatum |
+----+---------------------+---------------------+
| 1 | 09.12.2020 08:00:00 | 09.12.2020 08:00:00 |
+----+---------------------+---------------------+
1 Zeile im Satz (0,06 Sek.)

Diese Zeit scheint korrekt zu sein, also versuchen wir, die Zeitzone zu ändern und die Daten erneut einzugeben.

mysql> SETZE Zeitzone = "+00:00";
Abfrage OK, 0 Zeilen betroffen (0,03 Sek.)

mysql> einfügen in timestamp_test(erstellt_zeit, erstellt_am) Werte('2020-12-09 08:00:00', '2020-12-09 08:00:00');
Abfrage OK, 1 Zeile betroffen (0,03 Sek.)

mysql> SETZE Zeitzone = "+08:00";
Abfrage OK, 0 Zeilen betroffen (0,04 Sek.)

Überprüfen Sie nun die Daten erneut. Die beiden eingefügten SQL sind gleich, aber die Abfrageergebnisse sind unterschiedlich. Der Unterschied in created_at zwischen den beiden Daten ist genau der Zeitunterschied der Zeitzone.

mysql> wähle * aus Zeitstempel_test;
+----+---------------------+---------------------+
| ID | Erstellungszeit | Erstellungsdatum |
+----+---------------------+---------------------+
| 1 | 09.12.2020 08:00:00 | 09.12.2020 08:00:00 |
| 2 | 09.12.2020 08:00:00 | 09.12.2020 16:00:00 |
+----+---------------------+---------------------+
2 Reihen im Satz (0,06 Sek.)

Schauen wir uns den tatsächlich gespeicherten Zeitstempel an. Dann ändern wir die Zeitzone und stellen fest, dass sich die Feldzeit geändert hat, die ursprünglichen Zeitstempeldaten jedoch nicht geändert haben.

mysql> wähle *, unix_timestamp(erstellt am) aus timestamp_test;
+----+---------------------+---------+-------------------------+
| ID | Erstellungszeit | Erstellungsdatum | Unix-Zeitstempel(Erstellungsdatum) |
+----+---------------------+---------+-------------------------+
| 1 | 09.12.2020 08:00:00 | 09.12.2020 08:00:00 | 1607472000 |
| 2 | 09.12.2020 08:00:00 | 09.12.2020 16:00:00 | 1607500800 |
+----+---------------------+---------+-------------------------+
2 Reihen im Satz (0,06 Sek.)

mysql> SETZE Zeitzone = "+00:00";
Abfrage OK, 0 Zeilen betroffen (0,09 Sek.)

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

mysql> wähle *, unix_timestamp(erstellt am) aus timestamp_test;
+----+---------------------+---------+-------------------------+
| ID | Erstellungszeit | Erstellungsdatum | Unix-Zeitstempel(Erstellungsdatum) |
+----+---------------------+---------+-------------------------+
| 1 | 09.12.2020 08:00:00 | 09.12.2020 00:00:00 | 1607472000 |
| 2 | 09.12.2020 08:00:00 | 09.12.2020 08:00:00 | 1607500800 |
+----+---------------------+---------+-------------------------+
2 Reihen im Satz (0,18 Sek.)

Da MySQL all dies implizit für uns konvertiert, müssen wir uns keine Gedanken über Zeitzonenprobleme machen.

Die Datenbank speichert tatsächlich UTC-Zeitstempel. Beim Schreiben wird zunächst entsprechend der Sitzungszeitzone in die UTC-Zeit konvertiert. Beim Lesen wird entsprechend der Sitzungszeitzone in die aktuelle Zeitzone konvertiert. Diese Konvertierungen sind transparent.

  • Angenommen, wir speichern ein Datenelement 2020-12-09 08:00:00 in der positiven Achtelzone
  • Wir haben diese Daten in der achten Zone abgerufen und die Zeit ist immer noch 2020-12-09 08:00:00
  • Zu diesem Zeitpunkt haben wir einen Server in der Zeitzone Null, stellen eine Verbindung zu MySQL her und stellen die Zeitzone der aktuellen Verbindung auf +00:00 ein. Überprüfen Sie dann den Datenbankeintrag und die gefundenen Daten lauten: 2020-12-09 00:00:00 , was der Zeit der Zeitzone Null entspricht. Auf diese Weise müssen wir das Zeitzonenproblem nicht berücksichtigen.

Oben sind die Details, warum MySQL-Zeitstempel das Zeitzonenproblem ignorieren können. Weitere Informationen zum Ignorieren der Zeitzone durch MySQL-Zeitstempel finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!

Das könnte Sie auch interessieren:
  • Fallstricke bei langsamen MySQL-Abfragen
  • Beheben der Anomalie der MySQL-Datums-/Uhrzeitabfrage
  • SQL-Methode zum Berechnen der Zeitstempeldifferenz
  • Fallstricke und Lösungen bei der MySQL-Zeitstempelvergleichsabfrage

<<:  Erläuterung der Bedeutung des Head-Area-Codes anhand von HTML-Webseitenbeispielen

>>:  Docker verwendet das Tool nsenter, um in den Container zu gelangen

Artikel empfehlen

Implementierung einer kreisförmigen CSS-Aushöhlung (Gutschein-Hintergrundbild)

In diesem Artikel werden hauptsächlich kreisförmi...

Was sind die Dateiattribute von crw, brw, lrw usw. in Linux?

Was ist eine Datei? Eigentlich sind alle Dateien ...

Detaillierte Erklärung zum Anpassen des Linux-Befehlsverlaufs

Der Befehl „Bash History“ im Linux-System hilft d...

Detaillierte Erläuterung der Docker Volume-Berechtigungsverwaltung

Das Datenvolumen ist ein wichtiges Konzept von Do...

Detaillierte Erklärung, wo das von Docker abgerufene Image gespeichert ist

20200804Nachtrag: Der Artikel könnte falsch sein....

Detaillierte Erklärung der Rolle von Explain in MySQL

1. MySQL-Index Index: Eine Datenstruktur, die MyS...

Was ist TypeScript?

Inhaltsverzeichnis 1. JavaScript-Probleme 2. Vort...

So sammeln Sie Nginx-Protokolle mit Filebeat

Mithilfe von Nginx-Protokollen lassen sich Benutz...

So ändern Sie Flash-SWF-Dateien in Webseiten

Ich denke, dies ist ein Problem, auf das viele Leu...

Detaillierte Schritte zum Upgrade von mysql8.0.11 auf mysql8.0.17 unter Win2008

Upgrade-Hintergrund: Um die Sicherheitslücke in d...

Prinzip und Anwendungsbeispiele des URL-Umschreibmechanismus von Nginx

Durch das Umschreiben der URL lässt sich die bevo...

Typische Fälle von MySQL-Indexfehlern

Inhaltsverzeichnis Typische Fälle Anhang: Häufige...