建站
咨詢
售后
建站咨詢
新聞中心
如何修改mysql 時(shí)區(qū) 為system
1。在mysql的命令模式下使用
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司、屯溪網(wǎng)絡(luò)推廣、微信小程序、屯溪網(wǎng)絡(luò)營銷、屯溪企業(yè)策劃、屯溪品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供屯溪建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com
mysql
select
CURTIME();
或
mysql
select
now();
看當(dāng)前時(shí)間是否正確，可以看到mysql當(dāng)前使用的是那一個(gè)時(shí)區(qū)的時(shí)間。
2。在mysql命令行中更改時(shí)區(qū)
mysql
SET
time_zone
=
'+8:00';
#
此為北京時(shí)，我們所在東8區(qū)
mysql
flush
privileges;
#
立即生效
此時(shí)mysql時(shí)區(qū)已更改正確，與系統(tǒng)時(shí)區(qū)都使用為
Shanghai時(shí)間了。
####
這種方法好像只能在終端上使用，退出終端后時(shí)間又會變成原來的，看來只能重啟mysql了。
3。重啟mysql也應(yīng)沒有問題，此時(shí)mysql會主動讀取系統(tǒng)時(shí)間。
方法二：
如果mysql數(shù)據(jù)庫可以重啟，直接重啟，mysql應(yīng)可以立即主動讀取系統(tǒng)時(shí)間，如果不行則更改mysql的配置文件(mysql點(diǎn)吸煙 f)
在my點(diǎn)吸煙 f的
[mysqld]區(qū)域中加上
default-time_zone
=
'+8:00'
#此為北京時(shí)。
補(bǔ)充：
如果想臨時(shí)解決時(shí)間顯示問題，可以用php或其他語言動態(tài)修改下mysql的時(shí)區(qū)。
具體方法：
在mysql_connect()下使用mysql_query("SET
time_zone
=
'+8:00'")。
這樣可以在保證你不重啟的情況下改變時(shí)區(qū)。但是mysql的某些系統(tǒng)函數(shù)還是不能用如：now（）。
MySQL怎么設(shè)置時(shí)區(qū)為格林威治時(shí)間。
MySQL 時(shí)區(qū)默認(rèn)是服務(wù)器的時(shí)區(qū)。
查看：
復(fù)制代碼代碼如下:
mysql SHOW VARIABLES LIKE '%time_zone%';
+------------------+--------+
| Variable_name| Value |
+------------------+--------+
| system_time_zone | CST|
| time_zone| SYSTEM |
+------------------+--------+
2 rows IN SET (0.00 sec)
可以通過修改my點(diǎn)吸煙 f, 在 [mysqld] 之下加來修改時(shí)區(qū)。
default-time-zone=timezone
例如：
default-time-zone='+8:00'
修改后記得重啟msyql。
注意一定要在 [mysqld] 之下加 ，否則會出現(xiàn)錯誤: unknown variable ‘default-time-zone=+8:00′
另外也可以通過命令：
SET time_zone=timezone
例如：比如北京時(shí)間（GMT+0800）
SET time_zone='+8:00'
這個(gè)和php的時(shí)區(qū)設(shè)置又有點(diǎn)差別，比如北京時(shí)間在php中是：
date_default_timezone_set('Etc/GMT-8');
美國pst時(shí)間（GMT-08:00）
SET time_zone = '-8:00';
復(fù)制代碼代碼如下:
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)
mysql修改和查看時(shí)區(qū)（十五）
1. 查看時(shí)區(qū)命令
2.?GMT、UTC、DST、CST時(shí)區(qū)代表的意義
2.1 GMT：Greenwich Mean Time?
2.2?UTC: Coordinated Universal Time
2.3?DST: Daylight Saving Time
2.4?CST:Central Standard Time
3.? 修改時(shí)區(qū)
3.1?僅修改當(dāng)前會話的時(shí)區(qū)，停止會話失效(CET)
3.2 修改全局的時(shí)區(qū)配置
技術(shù)分享 | MySQL:一文弄懂時(shí)區(qū)&time_zone
你還在被以下問題困擾嗎：
MySQL 的安裝規(guī)范中應(yīng)該設(shè)置什么時(shí)區(qū)？
JAVA 應(yīng)用讀取到的時(shí)間和北京時(shí)間差了14個(gè)小時(shí)，為什么？怎么解決？
已經(jīng)運(yùn)行一段時(shí)間的業(yè)務(wù)，修改 MySQL 的時(shí)區(qū)會影響已經(jīng)存儲的時(shí)間類型數(shù)據(jù)嗎？
遷移數(shù)據(jù)時(shí)會有導(dǎo)致時(shí)間類型數(shù)據(jù)時(shí)區(qū)錯誤的可能嗎？
...
看完這篇文章，你能解決上面所有的疑惑。首先出場的是和時(shí)區(qū)相關(guān)的啟動參數(shù)和系統(tǒng)變量。
如果要在 MySQL 啟動時(shí)就指定時(shí)區(qū)，則應(yīng)該使用啟動參數(shù)： default-time-zone ，示例：
啟動后我們可以看到控制時(shí)區(qū)的系統(tǒng)變量，其中 time_zone 變量控制時(shí)區(qū)，在MySQL運(yùn)行時(shí)可以通過 set 命令修改（注意：不可以寫在 my點(diǎn)吸煙 f 中）：
啟動參數(shù)和系統(tǒng)變量的可用值遵循相同的格式：
system_time_zone 變量只有全局值沒有會話值，不能動態(tài)修改，MySQL 啟動時(shí)，將嘗試自動確定服務(wù)器的時(shí)區(qū)，并使用它來設(shè)置 system_time_zone 系統(tǒng)變量， 此后該值不變。當(dāng) time_zone='system' 時(shí)，就是使用的這個(gè)時(shí)區(qū)，示例中 time_zone 就是 CST，而 CST 在 RedHat 上就是東八區(qū)：
概括一下就兩點(diǎn)：
1. NOW() 和 CURTIME() 系統(tǒng)函數(shù)的返回值受當(dāng)前 session 的時(shí)區(qū)影響
不僅是select now()，包括insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 屬性也受此影響：
2. timestamp 數(shù)據(jù)類型字段存儲的數(shù)據(jù)受時(shí)區(qū)影響
timestamp 數(shù)據(jù)類型會存儲當(dāng)時(shí)session的時(shí)區(qū)信息，讀取時(shí)會根據(jù)當(dāng)前 session 的時(shí)區(qū)進(jìn)行轉(zhuǎn)換；而 datetime 數(shù)據(jù)類型插入的是什么值，再讀取就是什么值，不受時(shí)區(qū)影響。也可以理解為已經(jīng)存儲的數(shù)據(jù)是不會變的，只是 timestamp 類型數(shù)據(jù)在讀取時(shí)會根據(jù)時(shí)區(qū)轉(zhuǎn)換：
關(guān)于時(shí)區(qū)所有明面上的東西都在上面了，我們前面提到的困擾就是在暗處的經(jīng)驗(yàn)。
1. MySQL的安裝規(guī)范中應(yīng)該設(shè)置什么時(shí)區(qū)？
對于國內(nèi)的業(yè)務(wù)了，在 my點(diǎn)吸煙 f 寫入 default-time-zone='+08:00' `，其他地區(qū)和開發(fā)確認(rèn)取對應(yīng)時(shí)區(qū)即可。
為什么不設(shè)置為 system 呢？使用系統(tǒng)時(shí)間看起來也是個(gè)不錯的選擇，比較省事。不建議的原因有兩點(diǎn)：
2. JAVA應(yīng)用讀取到的時(shí)間和北京時(shí)間差了14個(gè)小時(shí)，為什么？怎么解決？
這通常是 JDBC 參數(shù)中沒有為連接設(shè)置時(shí)區(qū)屬性（用 serverTimezone 參數(shù)指定），并且MySQL中沒有設(shè)置全局時(shí)區(qū)，這樣MySQL默認(rèn)使用的是系統(tǒng)時(shí)區(qū)，即 CST。這樣一來應(yīng)用與MySQL 建立的連接的 session time_zone 為 CST ，前面我們提到 CST 在 RedHat 上是 +08:00 時(shí)區(qū)，但其實(shí)它一共能代表4個(gè)時(shí)區(qū)：
JDBC在解析CST時(shí)使用了美國標(biāo)準(zhǔn)時(shí)間，這就會導(dǎo)致時(shí)區(qū)錯誤。要解決也簡單：一是遵守上面剛說到的規(guī)范，對MySQL顯示的設(shè)置'+08:00'時(shí)區(qū)；二是JDBC設(shè)置正確的 serverTimezone。
3. 已經(jīng)運(yùn)行一段時(shí)間的業(yè)務(wù)，修改MySQL的時(shí)區(qū)會影響已經(jīng)存儲的時(shí)間類型數(shù)據(jù)嗎？
完全不會，只會影響對 timestamp 數(shù)據(jù)類型的讀取。這里不得不提一句，為啥要用 timestamp？用 datetime 不香嗎，范圍更大，存儲空間其實(shí)差別很小，趕緊加到開發(fā)規(guī)范中吧。
4. 遷移數(shù)據(jù)時(shí)會有導(dǎo)致時(shí)間類型數(shù)據(jù)時(shí)區(qū)錯誤的可能嗎？
這個(gè)還真有，還是針對 timestamp 數(shù)據(jù)類型，比如使用 mysqldump 導(dǎo)出 csv 格式的數(shù)據(jù)，默認(rèn)這種導(dǎo)出方式會使用 UTC 時(shí)區(qū)讀取 timestamp 類型數(shù)據(jù)，這意味導(dǎo)入時(shí)必須手工設(shè)置 session.time_zone='+00:00'才能保證時(shí)間準(zhǔn)確：
如何避免？mysqldump 也提供了一個(gè)參數(shù) --skip-tz-utc ，意思就是導(dǎo)出數(shù)據(jù)的那個(gè)連接不設(shè)置 UTC 時(shí)區(qū)，使用 MySQL 的 gloobal time_zone 系統(tǒng)變量值。
其實(shí) mysqldump 導(dǎo)出 sql 文件時(shí)默認(rèn)也是使用 UTC 時(shí)區(qū)，并且會在導(dǎo)出的 sql 文件頭部帶有 session time_zone 信息，這樣可以保證導(dǎo) SQL 文件導(dǎo)入和導(dǎo)出時(shí)使用相同的時(shí)區(qū)，從而保證數(shù)據(jù)的時(shí)區(qū)正確（而導(dǎo)出的 csv 文件顯然不可以攜帶此信息）。需要注意的是 --compact 參數(shù)會去掉 sql 文件的所有頭信息，所以一定要記得： --compact 參數(shù)得和 --skip-tz-utc 一起使用。
本文題目：怎么看mysql時(shí)區(qū) mysql查時(shí)間區(qū)間
轉(zhuǎn)載來源：http://www.dlmjj.cn/article/ddeeidj.html
