修改mysql服務器默認時區,mysql配置文件設置時區

本文目錄一覽：

• 1、我們公司使用的是亞馬遜雲AWS,請問如何修改AWS的RDS-MYSQL數據庫的默認時區？
• 2、如何在MySQL中修改時區
• 3、MySQL:一文弄懂時區&time_zone
• 4、MySQL怎麼設置時區為格林威治時間。

我們公司使用的是亞馬遜雲AWS,請問如何修改AWS的RDS-MYSQL數據庫的默認時區？

您可以通過修改AWS參數組的參數：time_zone修改MySQL的時區。關於如何修改亞馬遜AWS參數：AWS參數是動態的，所以修改後立即生效。

對於已經建立的連接，不生效；對於新建立的連接才生效。

如果您創建了只讀副本，您可以為主庫和讀從庫設置不同的時區。

如果是從快照恢複數據庫，時區將會被設置成UTC

如果是恢復到時間點，時區將會保持和原庫一致

如何在MySQL中修改時區

通過以下參數來進行時區設置：

1. an absolute offset–絕對偏移量 例： alter session set time_zone = ‘-05:00’

2. database time zone–數據庫時區 例：alter session set time_zone = dbtimezone 這是數據庫默認的時區

3. os local time zone–操作系統本地時區 例：alter session set time_zone = local 獲得系統本地時區

4. a named region–直接用名字指定時區 例：alter session set time_zone = ‘america/new_york’

MySQL:一文弄懂時區&time_zone

你還在被以下問題困擾嗎：

MySQL的安裝規範中應該設置什麼時區？

JAVA應用讀取到的時間和北京時間差了14個小時，為什麼？怎麼解決？

已經運行一段時間的業務，修改MySQL的時區會影響已經存儲的時間類型數據嗎？

遷移數據時會有導致時間類型數據時區錯誤的可能嗎？

…

看完這篇文章，你能解決上面所有的疑惑。首先出場的是和時區相關的啟動參數和系統變量。

如果要在 MySQL 啟動時就指定時區，則應該使用啟動參數： default-time-zone ，示例：

啟動後我們可以看到控制時區的系統變量，其中 time_zone 變量控制時區，在MySQL運行時可以通過 set 命令修改（注意：不可以寫在 my.cnf 中）：

啟動參數和系統變量的可用值遵循相同的格式：

system_time_zone 變量只有全局值沒有會話值，不能動態修改，MySQL 啟動時，將嘗試自動確定服務器的時區，並使用它來設置 system_time_zone 系統變量， 此後該值不變。當 time_zone=’system’ 時，就是使用的這個時區，示例中 time_zone 就是 CST，而 CST 在 RedHat 上就是東八區：

概括一下就兩點：

不僅是select now()，包括insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 屬性也受此影響：

timestamp 數據類型會存儲當時session的時區信息，讀取時會根據當前 session 的時區進行轉換；而 datetime 數據類型插入的是什麼值，再讀取就是什麼值，不受時區影響。也可以理解為已經存儲的數據是不會變的，只是 timestamp 類型數據在讀取時會根據時區轉換：

關於時區所有明面上的東西都在上面了，我們前面提到的困擾就是在暗處的經驗。

1. MySQL的安裝規範中應該設置什麼時區？

對於國內的業務了，在 my.cnf 寫入 default-time-zone=’+08:00′ ，其他地區和開發確認取對應時區即可。

為什麼不設置為 system 呢？使用系統時間看起來也是個不錯的選擇，比較省事。不建議的原因有兩點：

2. JAVA應用讀取到的時間和北京時間差了14個小時，為什麼？怎麼解決？

這通常是 JDBC 參數中沒有為連接設置時區屬性（用 serverTimezone 參數指定），並且MySQL中沒有設置全局時區，這樣MySQL默認使用的是系統時區，即 CST。這樣一來應用與MySQL 建立的連接的 session time_zone 為 CST ，前面我們提到 CST 在 RedHat 上是 +08:00 時區，但其實它一共能代表4個時區：

JDBC在解析CST時使用了美國標準時間，這就會導致時區錯誤。要解決也簡單：一是遵守上面剛說到的規範，對MySQL顯式地設置’+08:00’時區；二是JDBC設置正確的 serverTimezone。

3. 已經運行一段時間的業務，修改MySQL的時區會影響已經存儲的時間類型數據嗎？

完全不會，只會影響對 timestamp 數據類型的讀取。這裡不得不提一句，為啥要用 timestamp？用 datetime 不香嗎，範圍更大，存儲空間其實差別很小，趕緊加到開發規範中吧。

4. 遷移數據時會有導致時間類型數據時區錯誤的可能嗎？

這個還真有。

如何避免？mysqldump 也提供了一個參數 –skip-tz-utc ，意思就是導出數據的那個連接不設置 UTC 時區，使用 MySQL 的 global time_zone 系統變量值。

其實 mysqldump 導出 sql 文件時默認也是使用 UTC 時區，並且會在導出的 sql 文件頭部帶有 session time_zone 信息，這樣可以保證導 SQL 文件導入和導出時使用相同的時區，從而保證數據的時區正確（而導出的 csv 文件顯然不可以攜帶此信息）。需要注意的是 –compact 參數會去掉 sql 文件的所有頭信息，所以一定要記得： –compact 參數得和 –skip-tz-utc 一起使用。

MySQL怎麼設置時區為格林威治時間。

MySQL 時區默認是服務器的時區。

查看：

複製代碼代碼如下:

mysql SHOW VARIABLES LIKE ‘%time_zone%’;

+——————+——–+

| Variable_name| Value |

+——————+——–+

| system_time_zone | CST|

| time_zone| SYSTEM |

+——————+——–+

2 rows IN SET (0.00 sec)

可以通過修改my.cnf, 在 [mysqld] 之下加來修改時區。

default-time-zone=timezone

例如：

default-time-zone=’+8:00′

修改後記得重啟msyql。

注意一定要在 [mysqld] 之下加 ，否則會出現錯誤: unknown variable 『default-time-zone=+8:00′

另外也可以通過命令：

SET time_zone=timezone

例如：比如北京時間（GMT+0800）

SET time_zone=’+8:00′

這個和php的時區設置又有點差別，比如北京時間在php中是：

date_default_timezone_set(‘Etc/GMT-8’);

美國pst時間（GMT-08:00）

SET time_zone = ‘-8:00’;

複製代碼代碼如下:

mysql SET time_zone = ‘+8:00’;

Query OK, 0 rows affected (0.00 sec)

mysql SELECT now();

+———————+

| now() |

+———————+

| 2008-12-29 11:26:36 |

+———————+

1 row IN SET (0.00 sec)

mysql SET time_zone = ‘-8:00’;

Query OK, 0 rows affected (0.00 sec)

mysql SELECT now();

+———————+

| now() |

+———————+

| 2008-12-28 19:27:09 |

+———————+

1 row IN SET (0.00 sec)