关于time_zone
当前时区。此变量用于初始化连接的每个客户端的时区。默认情况下，它的初始值是'SYSTEM'(这意味着，"使用system_time_zone的值"，即MySQL的时区和操作系统的时区相同)。例：
# date Sat Sep 18 11:21:56 CST 2021 mysql> show global variables like "%time_zone%"; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | CST | | time_zone | SYSTEM | +------------------+--------+ mysql> select now(); +---------------------+ | now() | +---------------------+ | 2021-09-18 11:22:04 | +---------------------+
阿里云RDS MySQL的time_zone
目前RDS MySQL的只读实例单独申请，规格和参数和主实例的可以不一样，如time_zone，也可以根据自己的需求改成对应的时区。
时区不同写入数据一致
对于写语句(DML&&DDL)，阿里云RDS MySQL从主实例写入且binlog_format是row模式，所以写入的数据不会不一致。但如果是线下自建的MySQL binlog_format可以是statement或mix，可能会造成主从数据不一致。
例(以下操作在RDS MySQL上执行)：
CREATE TABLE `test_t1` ( `id` int DEFAULT NULL, `tt` DATETIME DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 INSERT INTO test_t1 values(1,"2021-09-17 15:16:00");
主实例上：
Table |
Checksum |
ll_test00.test_t1 |
1279576785 |
只读实例上：
Table |
Checksum |
ll_test00.test_t1 |
1279576785 |
然后执行：
INSERT INTO test_t1 values(10000,now());
主实例上：
Table |
Checksum |
ll_test00.test_t1 |
4230977686 |
只读实例上：
Table |
Checksum |
ll_test00.test_t1 |
4230977686 |
checksum一致说明只读和主写入的数据是一致的。
时区不同查询结果可能不同
当主实例和只读实例的default_time_zone参数设置不一样时，如果有涉及到下列语句时会导致取到的结果不一致，所以最保险起见是把只读实例和主实例的参数设置一致，也有个别用户根据业务需要专门设置不一致，具体还需要根据实际业务需求决定。
select now();select from_unixtime(秒数);select unix_timestamp();select current_timestamp, current_timestamp();select date_add(now(), interval n day);以下没问题： select date_format('2018-08-12 02:13:01','%Y%m%d%H%i%s');select sec_to_time(1801);select date_sub('2008-02-01 12:00:00', interval '2 3:3:4' day_second);select timestampadd(hour,-6,'2018-12-08 23:03:00');
例1：
mysql>select now();
主实例：
now() |
2021-09-17 15:55:56 |
只读实例和主实例2个小时的时差：
now() |
2021-09-17 13:56:01 |
例2:
mysql>SELECT*FROM test_t1;
在主实例和只读实例上的结果一致：
id |
tt |
1 |
2021-09-17 15:16:00 |
10000 |
2021-09-17 15:22:57 |
再在主实例和只读实例分别执行:
mysql>SELECT*FROM test_t1 where tt >= date_add(now(), interval 1 hour);
主实例的结果：
只读实例的结果：
扩展
MySQL官网上提到“If set to SYSTEM, every MySQL function call that requires a time zone calculation makes a system library call to determine the current system time zone. This call may be protected by a global mutex, resulting in contention.” 这会导致CPU高。可以参考看具体的内核信息：MySQL数据库SYS CPU高的可能性分析 http://mysql.taobao.org/monthly/2015/05/02/ 。
例：
mysql >CREATETABLE `test_tz` ( `id` bigint(20)NOTNULL AUTO_INCREMENT, `cc` bigint(20) DEFAULT NULL, `kk` varchar(128) DEFAULT NULL, `pad` varchar(64) DEFAULT NULL, `at` timestampNOTNULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;造数据 # mysqlslap --host=127.0.0.1 --password=3306 --user=*** --password=*** --query="insert into mysqlslap.test_tz(cc,kk,pad,at) values(connection_id(),'31451373586-15688153734-79729593694-96509299839-83724898275-86711833539-78981337422-35049690573-51724173961-87474696253','98996621624-36689827414-04092488557-09587706818-65008859162',now());" --concurrency=20 --no-drop --iterations=100000压测 # mysqlslap --host=127.0.0.1 --password=3306 --user=*** --password=*** --query="select count(*) from mysqlslap.test_tz where at>='2021-09-17 17:48:00' and at<='2021-09-17 17:56:00'" --concurrency=32,64,128,256,512 --no-drop --iterations=100
经压测发现，当time_zone=SYSTEM时，sys_cpu占比10%左右；default_time_zone=+08:00时，sys_cpu基本不变。所以建议客户不要使用time_zone=SYSTEM。
参考
https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_time_zone
