MySQLのDATETIMEとTIMESTAMP、どちらを使うべき?違いと使い分けを実例で解説
MySQLには日付と時刻を扱うためのデータ型として「DATETIME」と「TIMESTAMP」があります。どちらも似た用途で使用されますが、内部の動作には重要な違いがあります。本記事では、TIMESTAMP型の基本的な使い方を実際のSQL例とともに紹介し、両者の使い分けのポイントについても解説します。
TIMESTAMP型とは
TIMESTAMPはMySQLの日付・時刻データ型の一つで、「YYYY-MM-DD HH:MM:SS」形式で値を保持します。DATETIMEとの最大の違いは、タイムゾーン(時間帯)の影響を受ける点です。TIMESTAMP型の値はUTC(協定世界時)で保存され、取得時に接続セッションのタイムゾーンへ自動的に変換されます。そのため、世界中の異なる地域から同じデータベースを利用するシステムに適したデータ型です。
テーブルの作成
まず、TIMESTAMP型のカラムを持つテーブルを作成します。
mysql> CREATE table TimeStampDemo
-> (
-> MyDataTime timestamp
-> );
Query OK, 0 rows affected (0.57 sec)
レコードの挿入
テーブル作成後、INSERT文を使って現在の日時を挿入します。NOW()関数は実行時点の日付と時刻を返すため、現在時刻を簡単に記録できます。
mysql> INSERT into TimeStampDemo values (now());
Query OK, 1 row affected (0.12 sec)
レコードの表示
挿入したデータはSELECT文で確認できます。
mysql> SELECT * from TimeStampDemo;
クエリを実行すると、以下のような結果が出力されます。
+---------------------+
| MyDataTime |
+---------------------+
| 2018-10-11 17:30:38 |
+---------------------+
1 row in set (0.00 sec)
DATETIMEとTIMESTAMPの使い分けのポイント
- TIMESTAMP: タイムゾーンの自動変換が必要なケースや、レコードの作成日時・更新日時を自動記録したい場合に最適です。ただし、扱える範囲は「1970-01-01 00:00:01 UTC」から「2038-01-19」までと限られており、いわゆる「2038年問題」に注意が必要です。
- DATETIME: タイムゾーンに依存しない絶対的な日時をそのまま保存したい場合に適しています。「1000-01-01」から「9999-12-31」までの広い範囲を扱えるため、長期間の日付データにも対応できます。
このように、多国籍サービスやログの時刻正規化にはTIMESTAMP、歴史的な日付やタイムゾーン非依存のデータにはDATETIMEを選ぶのが基本です。システム要件に合わせて適切なデータ型を選択しましょう。
-
DebianとUbuntu:どちらを選ぶべき?初心者向け徹底比較ガイド
Ubuntuは初期のリリースで多くの支持を集めました。Linuxベースのディストリビューションの世界に足を踏み入れたばかりの初心者にとって、一見複雑に見える操作を簡単にしてくれたからです。しかし、Unityインターフェースが登場した頃から、批判を受けるようにもなりました。客観的に言えば、そのインターフェース自体は良くも悪くもなく、役割をしっかり果たしていました。ただ、多くのユーザーが慣れ親しんだものとは異なるアプローチだったのです。その後、ランチャーメニューへの広告挿入やインターフェースのGnomeへの変更などが重なり、このディストリビューションを嫌うユーザーがさらに増え、代替手段を探す人が現
-
GRUBとsystemd-boot徹底比較:どちらのブートローダーを選ぶべきか?
systemd-bootは、かつて「gummiboot」と呼ばれていた、GRUBの新しいライバルとなるブートローダーです。対応するEFIシステム上では、GRUBの代わりにsystemd-bootを使ってOSを起動できます。大まかに言えば、systemd-bootはUEFIにすでに搭載されているブート機能へのインターフェースとして動作し、OSを選択するための最小限の機能だけを提供します。一方のGRUBは、「まるで一つのOSのようなもの」と表現されることもあるほど多くの機能を読み込んでユーザーのOS起動を管理しており、はるかに高い柔軟性を持っています。 ブートローダーとは何か? ブートローダーは