Erläuterung des Problems bei der Auswahl des MySQL-Speicherzeittyps

Der datetime-Typ wird normalerweise zum Speichern von Zeit in MySQL verwendet, aber viele Systeme verwenden jetzt auch int zum Speichern von Unix-Zeitstempeln. Was ist der Unterschied zwischen ihnen? Mein Fazit lautet wie folgt:

int

(1) 4 Byte Speicher. Die Länge von INT beträgt 4 Byte, was weniger Speicherplatz beansprucht als datatime. Der Speicherplatz des int-Index ist ebenfalls relativ klein und die Sortier- und Abfrageeffizienz ist relativ hoch.

(2) Die Lesbarkeit ist äußerst schlecht und die Daten können nicht intuitiv erkannt werden

ZEITSTEMPEL

(1) 4 Byte Speicher

(2) Die Werte werden im UTC-Format gespeichert

(3) Zeitzonenumrechnung: Umrechnung in die aktuelle Zeitzone beim Speichern und Rückrechnung in die aktuelle Zeitzone beim Abrufen.

(4) TIMESTAMP-Werte dürfen nicht vor 1970 oder nach 2037 liegen

Datum/Uhrzeit

(1) 8 Byte Speicherplatz

(2) Unabhängig von der Zeitzone

(3) Abrufen und Anzeigen von DATETIME-Werten im Format „JJJJ-MM-TT HH:MM:SS“. Der unterstützte Bereich ist „1000-01-01 00:00:00“ bis „9999-12-31 23:59:59“.

Da die MySQL-Leistung immer besser wird, denke ich, dass die zeitliche Speichermethode von persönlichen Gewohnheiten und Projektanforderungen abhängt.

Teilen Sie zwei Artikel über Int vs. Timestamp vs. Datetime-Leistungstests

MySQL DATETIME vs. TIMESTAMP vs. INT-Tester

Tabelle „test_datetime“ erstellen (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`datetime` FELDTYP NICHT NULL,
PRIMÄRSCHLÜSSEL (`id`)
)ENGINE=MyISAM;

Modellkonfiguration

• Kippverriegelung
• Schlüsselpuffer = 128 M
• max_zulässiges_Paket = 1M
• Tabellencache = 512
• Sortierpuffergröße = 2 M
• Lesepuffergröße = 2 M
• read_rnd_buffer_size = 8M
• myisam_sort_buffer_size = 8M
• Thread-Cache-Größe = 8
• query_cache_type = 0
• query_cache_size = 0
• Thread_Parallelität = 4

prüfen

DATUMZEIT 14111 14010 14369 130000000
ZEITSTEMPEL 13888 13887 14122 90000000
INT 13270 12970 13496 90000000

MySQL ausführen

mysql> wähle * von test_datetime in Ausgabedatei '/tmp/test_datetime.sql';
Abfrage OK, 10000000 Zeilen betroffen (6,19 Sek.)

mysql> wähle * aus test_timestamp in Ausgabedatei '/tmp/test_timestamp.sql';
Abfrage OK, 10000000 Zeilen betroffen (8,75 Sek.)

mysql> wähle * von test_int in Ausgabedatei '/tmp/test_int.sql';
Abfrage OK, 10000000 Zeilen betroffen (4,29 Sek.)

Tabelle test_datetime ändern, test_int umbenennen;
Tabelle ändern, test_int, Spalte datetimeint hinzufügen, INT NICHT NULL;
Aktualisiere test_int, setze datetimeint = UNIX_TIMESTAMP(datetime);
Tabelle ändern, Test_int, Spalte Datum/Uhrzeit löschen;
Tabelle ändern, test_int, Spalte ändern, datetimeint, datetime int nicht null;
Wählen Sie * aus test_int in die Ausgabedatei „/tmp/test_int2.sql“;
Tabelle test_int löschen;

Jetzt habe ich also genau dieselben Zeitstempel wie beim DATETIME-Test und es wird möglich sein, die Originale auch für TIMESTAMP-Tests wiederzuverwenden.

mysql> Daten in Datei '/export/home/ntavares/test_datetime.sql' in Tabelle test_datetime laden;
Abfrage OK, 10000000 Zeilen betroffen (41,52 Sek.)
Datensätze: 10000000 Gelöscht: 0 Übersprungen: 0 Warnungen: 0

mysql> Daten in Datei „/export/home/ntavares/test_datetime.sql“ in Tabelle „test_timestamp“ laden;
Abfrage OK, 10000000 Zeilen betroffen, 44 Warnungen (48,32 Sek.)
Datensätze: 10000000 Gelöscht: 0 Übersprungen: 0 Warnungen: 44

mysql> Daten in Datei „/export/home/ntavares/test_int2.sql“ in Tabelle test_int laden;
Abfrage OK, 10000000 Zeilen betroffen (37,73 Sek.)
Datensätze: 10000000 Gelöscht: 0 Übersprungen: 0 Warnungen: 0

Wie erwartet, da INT einfach so gespeichert wird, wie es ist, während die anderen neu berechnet werden müssen. Beachten Sie, dass TIMESTAMP immer noch schlechter abschneidet, obwohl es die Hälfte der DATETIME-Speichergröße verwendet.

Lassen Sie uns die Leistung des vollständigen Tabellenscans überprüfen:

mysql> SELECT SQL_NO_CACHE count(id) FROM test_datetime WHERE datetime > '1970-01-01 01:30:00' UND datetime < '1970-01-01 01:35:00';
+———–+
| Anzahl(ID) |
+———–+
|211991|
+———–+
1 Zeile im Satz (3,93 Sek.)

mysql> SELECT SQL_NO_CACHE count(id) FROM test_timestamp WHERE datetime > ‚1970-01-01 01:30:00‘ AND datetime < ‚1970-01-01 01:35:00‘;
+———–+
| Anzahl(ID) |
+———–+
|211991|
+———–+
1 Reihe im Satz (9,87 Sek.)

mysql> SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime > UNIX_TIMESTAMP('1970-01-01 01:30:00′) AND datetime < UNIX_TIMESTAMP('1970-01-01 01:35:00′);
+———–+
| Anzahl(ID) |
+———–+
|211991|
+———–+
1 Reihe im Satz (15,12 Sek.)

Andererseits weist TIMESTAMP eine schlechtere Leistung auf und die Neuberechnungen scheinen sich auszuwirken, sodass der nächste gute Test ohne diese Neuberechnungen auskommt: Suchen Sie die Äquivalente dieser UNIX_TIMESTAMP()-Werte und verwenden Sie sie stattdessen:

mysql> wähle UNIX_TIMESTAMP('1970-01-01 01:30:00′) AS niedriger, UNIX_TIMESTAMP('1970-01-01 01:35:00′) AS größer;
+——-+——–+
| niedriger | größer |
+——-+——–+
| 1800 | 2100 |
+——-+——–+
1 Zeile im Satz (0,00 Sek.)

mysql> SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime > 1800 AND datetime < 2100;
+———–+
| Anzahl(ID) |
+———–+
|211991|
+———–+
1 Reihe im Satz (1,94 Sek.)

MySQL DATETIME vs. TIMESTAMP vs. INT-Leistung und Benchmarking mit InnoDB

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an