在進行跨資料庫開發或資料庫遷移時，時間戳記欄位（如 DATETIME ）的精度差異常常導致資料遺失、主鍵衝突、程式錯誤等問題。本文深入分析 MySQL 與 Microsoft SQL Server 在 DATETIME 與 DATETIME2 型態上的差異，並提供移轉注意事項與最佳解法，幫助你避免踩雷。一、MySQL 與 SQL Server 的 DATETIME 精度與格式差異 1. SQL Server 的 DATETIME 與 DATETIME2 DATETIME ：精度到「毫秒」(小數點後 3 位，.123) 例： 2024-03-28 13:09:58.343 DATETIME2(n) ：精度最高到「百奈秒」(小數點後 7 位，.1234567) 可調整 n（小數位數），預設 n=7 例： 2024-03-28 13:09:58.3433333 2. MySQL 的 DATETIME DATETIME （預設）：精度僅到「秒」(無小數) 例： 2025-07-23 14:13:51 DATETIME(fsp) ： fsp 參數代表小數點後幾位，可達 6（微秒 .123456）例： 2025-07-23 14:13:51.343333 最大僅支援 DATETIME(6) （微秒），無法到達百奈秒精度。二、精度差異帶來的實務影響主鍵衝突問題若以 DATETIME 作為主鍵，SQL Server 可用到毫秒甚至微秒，MySQL 若未設定 fsp，僅到秒，同一秒多次寫入就會主鍵衝突。資料遺失/截斷 SQL Server 匯出時間戳記至 MySQL 時，若精度超過 MySQL 支援會自動截斷小數，可能造成時間資訊遺失。資料庫移轉與相容性移轉資料表結構時，必須明確指定 MySQL 的 DATETIME(3) 或 DATETIME(6) ，以對應 SQL Server 的毫秒或微秒精度。程式邏輯需調整依據不同資料庫精度，應避免直接用時間當主鍵，建議使用自動遞增欄位或 UUID，確保唯一性。三、資料庫移轉最佳實務與建議移轉前比對精度移轉資料表時，檢查所有時間欄位的型態與精度，確保對應 MySQL 欄位有正確的小數精度設定（如 DATETIME(3) ）。避免用時間作為主鍵強烈建議改用 INT AUTO_INCREMENT 或 BIGINT 自動遞增作為主鍵，時間欄位只作為一般紀錄。程式端處理注意 JavaScript（Node.js）只能產生毫秒（3位），無法產生微秒、百奈秒級時間戳，若用更高精度會自動補 0。資料批次轉移時注意資料截斷匯入資料時，需注意小數截斷，避免重複或遺失紀錄。四、常見問答 Q1：MySQL 可以和 SQL Server 一樣支援 7 位小數嗎？不行，MySQL DATETIME 最多支援到 6 位（微秒），SQL Server DATETIME2 可到 7 位（百奈秒）。 Q2：時間當主鍵會有哪些風險？若精度不夠高（MySQL 只到秒或毫秒），同一秒/毫秒多筆寫入就會主鍵重複，導致寫入失敗。 Q3：MySQL 資料表該如何設定 DATETIME 精度？以 Prisma 為例： @db.DateTime(3) 或 @db.DateTime(6) 以 SQL 指令： DATETIME(3) 或 DATETIME(6) 五、結論 MySQL 與 SQL Server 在 DATETIME 精度上存有本質差異，資料庫移轉或系統開發時必須特別注意。建議日誌或歷史資料表盡量不要直接用時間戳記作為主鍵，而應搭配自動遞增主鍵或其他唯一識別機制，這樣才能確保系統穩定且易於維護。延伸閱讀關鍵字： MySQL DATETIME 精度 SQL Server DATETIME2 移轉資料庫主鍵設計 MySQL SQL Server 資料相容 Prisma DateTime 精度設定

MySQL 與 SQL Server DATETIME 精度差異詳解：資料庫移轉常見問題與最佳實務

萌芽站長

在進行跨資料庫開發或資料庫遷移時，時間戳記欄位（如 DATETIME）的精度差異常常導致資料遺失、主鍵衝突、程式錯誤等問題。本文深入分析 MySQL 與 Microsoft SQL Server 在 DATETIME 與 DATETIME2 型態上的差異，並提供移轉注意事項與最佳解法，幫助你避免踩雷。

一、MySQL 與 SQL Server 的 DATETIME 精度與格式差異

1. SQL Server 的 DATETIME 與 DATETIME2

DATETIME：
- 精度到「毫秒」(小數點後 3 位，.123)
- 例：2024-03-28 13:09:58.343
DATETIME2(n)：
- 精度最高到「百奈秒」(小數點後 7 位，.1234567)
- 可調整 n（小數位數），預設 n=7
- 例：2024-03-28 13:09:58.3433333

2. MySQL 的 DATETIME

DATETIME（預設）：
- 精度僅到「秒」(無小數)
- 例：2025-07-23 14:13:51
DATETIME(fsp)：
- fsp 參數代表小數點後幾位，可達 6（微秒 .123456）
- 例：2025-07-23 14:13:51.343333
最大僅支援 DATETIME(6)（微秒），無法到達百奈秒精度。

二、精度差異帶來的實務影響

主鍵衝突問題
- 若以 DATETIME 作為主鍵，SQL Server 可用到毫秒甚至微秒，MySQL 若未設定 fsp，僅到秒，同一秒多次寫入就會主鍵衝突。
資料遺失/截斷
- SQL Server 匯出時間戳記至 MySQL 時，若精度超過 MySQL 支援會自動截斷小數，可能造成時間資訊遺失。
資料庫移轉與相容性
- 移轉資料表結構時，必須明確指定 MySQL 的 DATETIME(3) 或 DATETIME(6)，以對應 SQL Server 的毫秒或微秒精度。
程式邏輯需調整
- 依據不同資料庫精度，應避免直接用時間當主鍵，建議使用自動遞增欄位或 UUID，確保唯一性。

三、資料庫移轉最佳實務與建議

移轉前比對精度
- 移轉資料表時，檢查所有時間欄位的型態與精度，確保對應 MySQL 欄位有正確的小數精度設定（如 DATETIME(3)）。
避免用時間作為主鍵
- 強烈建議改用 INT AUTO_INCREMENT 或 BIGINT 自動遞增作為主鍵，時間欄位只作為一般紀錄。
程式端處理注意
- JavaScript（Node.js）只能產生毫秒（3位），無法產生微秒、百奈秒級時間戳，若用更高精度會自動補 0。
資料批次轉移時注意資料截斷
- 匯入資料時，需注意小數截斷，避免重複或遺失紀錄。

四、常見問答

Q1：MySQL 可以和 SQL Server 一樣支援 7 位小數嗎？

不行，MySQL DATETIME 最多支援到 6 位（微秒），SQL Server DATETIME2 可到 7 位（百奈秒）。

Q2：時間當主鍵會有哪些風險？

若精度不夠高（MySQL 只到秒或毫秒），同一秒/毫秒多筆寫入就會主鍵重複，導致寫入失敗。

Q3：MySQL 資料表該如何設定 DATETIME 精度？

以 Prisma 為例：@db.DateTime(3) 或 @db.DateTime(6)
以 SQL 指令：DATETIME(3) 或 DATETIME(6)

五、結論

MySQL 與 SQL Server 在 DATETIME 精度上存有本質差異，資料庫移轉或系統開發時必須特別注意。建議日誌或歷史資料表盡量不要直接用時間戳記作為主鍵，而應搭配自動遞增主鍵或其他唯一識別機制，這樣才能確保系統穩定且易於維護。

延伸閱讀關鍵字：

MySQL DATETIME 精度
SQL Server DATETIME2 移轉
資料庫主鍵設計
MySQL SQL Server 資料相容
Prisma DateTime 精度設定