測試場景

• 表 t1(id, add_time INT)，10 萬行數據
• 對比三種模式 10 萬行轉換耗時

測試代碼邏輯

// 1. PHP date() 轉換
SELECT add_time FROM t1 LIMIT 100000;
while ($row = fetch()) {
    date('Y-m-d H:i', $row['add_time']);
}

// 2. 無轉換基準 (純獲取)
SELECT add_time FROM t1 LIMIT 100000;
while ($row = fetch()) { /* 直接輸出 */ }

// 3. MySQL FROM_UNIXTIME() 轉換
SELECT FROM_UNIXTIME(add_time, '%Y-%m-%d %H:%i') AS add_time FROM t1 LIMIT 100000;
while ($row = fetch()) { /* 直接輸出 */ }

實測結果 (參考值，環境差異大)

模式	耗時 (秒)	相對性能
無轉換 (基準)	~0.30	1.0x
MySQL FROM_UNIXTIME()	~0.45	1.5x (含網絡傳輸)
PHP date()	~0.80	2.7x

結論：數據庫層轉換比應用層快 ~40-50%，但不可忽略數據庫 CPU 開銷。

深度分析

• 網絡傳輸量：格式化後字符串 (19 字節) > 整數 (4/8 字節)，增加帶寬
• CPU 分擔：DB 做格式化佔用 DB CPU；應用層做佔用 PHP CPU
• 連接池復用：長連接下 DB CPU 可能成為瓶頸
• 時區一致性：DB 統一格式化避免應用多實例時區不一致

最佳實踐建議

1. 小中型查詢/列表頁：用 FROM_UNIXTIME()，代碼簡潔、性能較好
2. 高併發核心接口：應用層 date()，保護 DB CPU，利用 PHP 多進程並行
3. 大數據導出/報表：DB 層格式化減少網絡傳輸 (若壓縮則無差異)
4. 統一時區：DB SET time_zone = '+08:00'，應用 date_default_timezone_set('PRC')
5. 避免重複轉換：不要 DB 格式化後 PHP 再解析格式化

擴展：MySQL 8.0 新函數

-- 更靈活的格式化
DATE_FORMAT(FROM_UNIXTIME(ts), '%Y-%m-%d %H:%i:%s')
-- 時區轉換
CONVERT_TZ(FROM_UNIXTIME(ts), '+00:00', '+08:00')