本文默認mysql版本大于5.7，之前版本對datetime不支持毫秒，同一個表里不允許有多個自動更新的時間字段

• 建表語句如下，創(chuàng)建時間和更新時間由數(shù)據(jù)庫自動維護、精確到毫秒。字符集utf8mb4、區(qū)分大小寫

CREATE TABLE IF NOT EXISTS `test`
(
    `id`          bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',
    `create_time`   datetime(3)         NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '創(chuàng)建時間',
    `update_time`   datetime(3)         NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '修改時間',
    PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT ='測試表';

• 現(xiàn)在都2021年了，時間字段就不要再用timestamp字段了
• datetime類型沒有和時區(qū)沒關系，比如在東八區(qū)寫入了2021-07-31 14:45:39.202，在東九區(qū)讀出來依然是2021-07-31 14:45:39.202
• CURRENT_TIMESTAMP函數(shù)根據(jù)mysql服務設置的時區(qū)，獲得對應時區(qū)的當前時間
• datetime在mysql存儲的時候實際存儲的就是20210731144539202這個數(shù)字，所以和時區(qū)無關
• 所以對跨境業(yè)務，在不同國家的數(shù)據(jù)庫最好約定好一個統(tǒng)一的時區(qū)，建議都用utf+0，這樣不同國家的服務從數(shù)據(jù)庫中讀出來在根據(jù)時區(qū)自己轉換就好

  出于合規(guī)要求，數(shù)據(jù)是不允許跨境流動的，所以不同國家的服務都應該有一個獨立的數(shù)據(jù)庫，而不是所有國家的服務公用一個數(shù)據(jù)庫。但是一些小公司做跨境電商類的可能不會這么規(guī)范，真的就是共用一個數(shù)據(jù)庫了