MySQL 時間戳與日期互轉：UNIX_TIMESTAMP 與 FROM_UNIXTIME 實戰指南

MySQL INT 時間戳與 DATETIME 互轉核心函數

在系統設計中，常需在「整數時間戳（INT）」與「日期時間（DATETIME）」之間轉換。MySQL 提供兩個核心函數完美支援此場景，效能極高且無時區困擾（以服務器時區為準）。

核心函數對照

實戰應用模式

建表設計建議

CREATE TABLE events (
  id INT PRIMARY KEY AUTO_INCREMENT,
  event_name VARCHAR(100),
  -- 使用 INT 存儲時間戳，節省空間且便於跨語言交互
  created_at INT UNSIGNED NOT NULL DEFAULT 0,
  updated_at INT UNSIGNED NOT NULL DEFAULT 0
);

插入數據（應用層或 SQL 直接轉換）

-- 方式一：應用層傳入時間戳
INSERT INTO events (event_name, created_at) VALUES ('用戶註冊', 1704067200);

-- 方式二：SQL 現場轉換
INSERT INTO events (event_name, created_at) 
VALUES ('訂單創建', UNIX_TIMESTAMP('2024-01-01 12:00:00'));

查詢與報表（格式化輸出）

-- 基礎轉換
SELECT event_name, FROM_UNIXTIME(created_at) AS created_dt FROM events;

-- 格式化輸出
SELECT event_name, DATE_FORMAT(FROM_UNIXTIME(created_at), '%Y-%m-%d %H:%i') AS created_fmt FROM events;

-- 範圍查詢（利用索引優勢）
SELECT * FROM events 
WHERE created_at BETWEEN UNIX_TIMESTAMP('2024-01-01') AND UNIX_TIMESTAMP('2024-01-31 23:59:59');

避坑指南

• 時區一致性：函數依賴 MySQL 服務器 time_zone 系統變量，確保寫入/讀取環境時區一致
• 年份 2038 問題：32 位有符號整數最大值對應 2038-01-19，長期項目建議使用 BIGINT 或原生 DATETIME
• 精度損失：秒級時間戳無法保存毫秒，高精度場景請用 DATETIME(3) 或 TIMESTAMP(3)
• 跨庫遷移：SQL Server 無對應函數，遷移時需在應用層統一轉換或使用 ETL 工具處理