MySQL Warum man bei der Verwendung von timestamps aufpassen sollte...

[Thomas Darimont]

Hallo,

Vorsicht bei der Verwendung von timestamp Spalten bei MySQL

mysql> create table time(id int, instant timestamp);
Query OK, 0 rows affected (0.20 sec)

mysql> insert into time values (1,now());
Query OK, 1 row affected (0.05 sec)

mysql> select * from time;
+------+---------------------+
| id   | instant             |
+------+---------------------+
|    1 | 2007-01-23 22:00:46 |
+------+---------------------+
1 row in set (0.00 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2007-01-23 22:01:02 |
+---------------------+
1 row in set (0.00 sec)

mysql> update time set id = 2 where id = 1;
Query OK, 1 row affected (0.06 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from time;
+------+---------------------+
| id   | instant             |
+------+---------------------+
|    2 | 2007-01-23 22:01:21 |
+------+---------------------+
1 row in set (0.00 sec)

Wie ihr seht wurde der Timestamp in der Spalte instant beim Update der Zeile mit geupdated ;-)
Das ist sicherlich nicht immer erwünscht und in anderen Datenbank System auch anders:

Beispielweise für DB2:

DB2 => create table time (id int, instant timestamp)
DB20000I  Der Befehl SQL wurde erfolgreich ausgeführt.
DB2 =>
DB2 => select CURRENT timestamp from sysibm.sysdummy1

1
--------------------------
2007-01-23-22.18.05.906000

  1 Satz/Sätze ausgewählt.

DB2 => insert into time values (1, CURRENT timestamp)
DB20000I  Der Befehl SQL wurde erfolgreich ausgeführt.
DB2 =>
DB2 => select * from time

ID          INSTANT
----------- --------------------------
          1 2007-01-23-22.18.26.968000

  1 Satz/Sätze ausgewählt.

DB2 => update  time set id = 2 where id = 1
DB20000I  Der Befehl SQL wurde erfolgreich ausgeführt.
DB2 =>
DB2 => select * from time

ID          INSTANT
----------- --------------------------
          2 2007-01-23-22.18.26.968000

  1 Satz/Sätze ausgewählt.

DB2 =>

Das kann insbesondere bei einer Datenbankmigration schon mal ne üble Überraschung geben ;-)

Wenn man statt timestamp den Typ datetime nimmt bekommt man das erwartete Verhalten:

mysql> create table datetime(id int, instant datetime);
Query OK, 0 rows affected (0.06 sec)

mysql> insert into datetime values (1,now());
Query OK, 1 row affected (0.02 sec)

mysql> select * from datetime;
+------+---------------------+
| id   | instant             |
+------+---------------------+
|    1 | 2007-01-23 22:09:20 |
+------+---------------------+
1 row in set (0.00 sec)

mysql> update datetime set id = 2 where id = 1;
Query OK, 1 row affected (0.11 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from datetime;
+------+---------------------+
| id   | instant             |
+------+---------------------+
|    2 | 2007-01-23 22:09:20 |
+------+---------------------+
1 row in set (0.00 sec)

Gruß Tom

 

[Gumbo]

Einfach mal nachschauen, was MySQL wirklich gemacht hat:

mysql> SHOW CREATE TABLE time\G
*************************** 1. row ***************************
       Table: time
Create Table: CREATE TABLE `time` (
  `id` int(11) default NULL,
  `instant` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
) ENGINE=MyISAM DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Eine Erklärung dieses Verhaltens bietet das MySQL-Handbuch: TIMESTAMP-Eigenschaften ab MySQL 4.1.