SQL日付フォーマット完全ガイド｜型・変換・高速化まで解説

「SQLで日付を扱うと、なぜかズレる」

「フォーマットを変えたら検索が遅くなった」

「MySQLとPostgreSQLで挙動が違って混乱する」

このような悩みは、“日付の扱い方の本質”を理解していないことが原因であるケースがほとんどです。

本記事では、以下を実務レベルで解説します。

• SQLの日付型（DATE / DATETIME / TIMESTAMP）の違い
• DB別（MySQL / PostgreSQL / Oracle / SQL Server）の注意点
• 日付フォーマット変換の正しい使い方
• パフォーマンスを落とさない検索・集計の書き方
• 現場でよくあるミスと回避方法

この記事を読むことで、日付処理のバグや性能問題を未然に防ぎ、設計レベルで正しい判断ができるようになります。

SQLの日付フォーマットの基本原則

保存と表示は分けて考える

SQLで日付を扱ううえで最も重要な考え方は以下です。

• 保存：日付型（DATE / DATETIMEなど）
• 表示：文字列（フォーマット変換）

この原則を守ることで、以下のメリットがあります。

• インデックスが効きやすい
• 比較・検索が高速になる
• タイムゾーンのズレを防げる

実務では、「検索・集計は日付型のまま」「表示直前だけ変換」が鉄則です。

SQLの日付・時刻データ型を理解する

DATE型｜日付のみを扱う

• 形式：YYYY-MM-DD
• 用途：
  • 誕生日
  • 契約日
  • 締め日

ポイント：
時刻を持たないため、日単位の処理がシンプルになります。

DATETIME型｜日時を正確に記録

• 形式：YYYY-MM-DD HH:MM:SS
• 用途：
  • 作成日時
  • 更新日時
  • イベントログ

ポイント：
秒単位の記録が可能で、業務ログに最適。

TIMESTAMP型｜タイムゾーンを意識した日時

• 特徴：
  • DBによって挙動が異なる
  • タイムゾーンの影響を受ける

用途例：

• 監査ログ
• 更新履歴

注意：
MySQLでは範囲制限やタイムゾーン依存があるため要注意。

DB別｜日付フォーマットと変換関数

MySQL

DATE_FORMAT（出力）

SELECT DATE_FORMAT(created_at, '%Y/%m/%d') FROM users;

STR_TO_DATE（入力）

SELECT STR_TO_DATE('2026/04/30', '%Y/%m/%d');

注意点：

• %mと%Mの違いに注意
• 曖昧な入力はバグの原因

PostgreSQL

TO_CHAR（出力）

SELECT TO_CHAR(created_at, 'YYYY-MM-DD');

TO_DATE / TO_TIMESTAMP（入力）

SELECT TO_DATE('20260430', 'YYYYMMDD');

Oracle

TO_CHAR

SELECT TO_CHAR(created_at, 'YYYY-MM-DD HH24:MI:SS') FROM dual;

注意点：

• DATE型でも時刻を含む
• NLS設定で表示が変わる

SQL Server

CONVERT

SELECT CONVERT(VARCHAR, created_at, 112);

FORMAT（非推奨ケースあり）

SELECT FORMAT(created_at, 'yyyy-MM-dd');

注意点：

• FORMATは遅い＆ロケール依存
• CONVERTの方が安定

実務で使う日付フォーマット設計

SELECTでの整形（正しい例）

SELECT 
  created_at,
  DATE_FORMAT(created_at, '%Y/%m/%d') AS display_date
FROM users;

ポイント：

• 元の日時も返す
• 表示用は別カラムにする

WHERE句でのNG例と改善

NG（遅くなる）

WHERE DATE(created_at) = '2026-04-30'

OK（高速）

WHERE created_at >= '2026-04-30 00:00:00'
  AND created_at <  '2026-05-01 00:00:00'

理由：
関数を使うとインデックスが効かないため。

日付計算の実務パターン

よくある要件：

• N日後
• 月末
• 締め日計算

注意点：

• DBごとに関数が異なる
• 月末処理はズレやすい

例（MySQL）：

SELECT DATE_ADD(created_at, INTERVAL 7 DAY);

SQLの日付処理でよくあるミス

1. タイムゾーンを考慮していない

対策：

• 保存はUTC
• 表示で変換

2. 文字列で日付を扱っている

'2026/04/30' ← NG

→ 型で扱うべき

3. 暗黙変換に依存している

環境によって解釈が変わる危険があります。

4. フォーマットと検索を混同

• フォーマット：表示専用
• 検索：日付型で行う

タイムゾーンとサマータイムの落とし穴

• 同じ時刻が2回存在する（DST）
• 存在しない時刻がある

推奨設計：

• DB：UTC保存
• フロント：ローカル表示

信頼性を高める参考情報

より詳細な仕様は公式ドキュメントを確認してください。

• MySQL公式：https://dev.mysql.com/doc/
• PostgreSQL公式：https://www.postgresql.org/docs/
• Oracle公式：https://docs.oracle.com/
• SQL Server：https://learn.microsoft.com/sql/

まとめ｜SQLの日付フォーマットの最適解

本記事のポイントを整理します。

• 日付は「保存」と「表示」を分離する
• 型選定が設計の8割を決める
• 検索では関数を使わない
• タイムゾーンは最初に設計する
• DBごとの差分を理解する

SQLの日付処理は、一見シンプルですが、

設計ミスがそのまま障害や性能問題につながる重要領域です。

次のステップ｜実務で使えるスキルへ

ここまで読んだ方は、単なるSQLの知識ではなく、

「実務で通用するデータ設計力」に興味があるはずです。

私たちのチームでも、

• 大規模データを扱う検索システム
• DB設計からパフォーマンスチューニングまで一貫対応
• 実務レベルのSQL設計・最適化

といった領域で、日々課題解決を行っています。

もし「もっと深く実務で活かしたい」「プロとして成長したい」と感じた方は、

同じ志を持つ仲間として、一緒に挑戦してみませんか。