Fallstricke und Lösungen bei der MySQL-Zeitstempelvergleichsabfrage

Fallstricke bei Zeitstempelvergleichsabfragen

Ich erinnere mich, dass JD.com bei der Erstellung einer Tabelle erforderte, dass MySQL „update_time“ als Zeitstempel und „create_time“ als Datum/Uhrzeit festlegte. Später verlangten die Codierungsstandards von Alibaba, dass beide vom Typ „Datetime“ sein müssen.

Der Unterschied zwischen Zeitstempel und Datum/Uhrzeit wird an vielen Stellen eingeführt. Manchmal frage ich mich, warum JD.com verlangt, dass update_time ein Zeitstempel ist? Liegt es daran, dass es weniger Platz einnimmt? Oder ist es nur möglich, einen Standardwert für den Zeitstempel festzulegen (beim Update des aktuellen Zeitstempels)? Kann der Standardwert datetime nicht auch festgelegt werden? Später suchte ich bei Baidu und fand heraus, dass die Datums- und Uhrzeitunterstützung zum Festlegen von Standardwerten nur in 5.7 verfügbar war. JD.com hat möglicherweise eine solche Anforderung, weil die zuvor verwendete MySQL-Version zu niedrig war und außerdem eine automatische Aktualisierung von update_time erforderlich war.

Da dies nun auch von einem Unternehmen verlangt wird, wird update_time auf den Zeitstempel gesetzt. Als Ergebnis bin ich in eine Grube geraten. Ein Kollege hat ein sehr merkwürdiges Problem festgestellt: Warum liefert die Datumsvergleichsabfrage keine Ergebnisse, obwohl die Ergebnisse durch die direkte Ausführung des im Protokoll gedruckten SQL abgefragt werden können? ? Warum tritt diese Inkonsistenz auf? Das ist mir noch nie passiert. Das Lösen von Problemen ist immer spannend.

Ich habe es vor Ort ausprobiert und es war tatsächlich der Fall. Es gab kein Problem mit dem gedruckten Protokoll, aber es war das Protokoll, das uns „verwirrte“ und uns ein sehr seltsames Gefühl gab. Ich habe es überprüft und festgestellt, dass das verglichene Feld update_time ist und vom Typ Zeitstempel ist. Unter dem Einfluss der Standards von Alibaba war ich fest davon überzeugt, dass es sich um ein Typproblem handeln müsste. Also habe ich bei Baidu gesucht und festgestellt, dass es ein Zeitzonenproblem war. Fügen Sie einfach den Parameter serverTimezone=GMT%2B8 nach der URL der Datenbankverbindung hinzu. Eine andere Möglichkeit besteht natürlich darin, Datum und Uhrzeit zu verwenden. Dadurch können viele Fallstricke vermieden werden.

Warum tritt dieses Problem auf? Dies liegt daran, dass die Zeitzone des Anwendungsservers und des Servers, auf dem MySQL bereitgestellt wird, nicht konsistent sind. Aus diesem Grund wird beim Drucken des Protokolls kein Problem angezeigt, es werden jedoch keine Abfrageergebnisse angezeigt (die im Protokoll angezeigte Zeit entspricht der Zeitzone des lokalen Computers, aber wenn die Daten an den MySQL-Server übertragen werden, entspricht dies der Zeit einer anderen Zeitzone).

Auch MySQL-Datum hat dieses Problem. . .

Problem mit dem Zeitstempelabfragebereich

Wenn in MySQL beispielsweise die Aktualisierungszeit 2020-05-26 ist, lautet die Abfrage update_time <= 2020-05-26 und kann nicht gefunden werden. Sie muss in DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26' konvertiert werden. Der genaue Grund ist unbekannt und muss weiter untersucht werden.

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.