MySQL时区不对应优先在my.cnf的[mysqld]段设置default-time-zone='+08:00'并重启，再验证@@global.time_zone；关键生产参数需调max_connections、innodb_buffer_pool_size等。
MySQL 启动后发现 SELECT NOW() 时间不对怎么办
安装完 MySQL 默认时区通常是 SYSTEM，也就是继承操作系统的时区设置。但很多 Linux 发行版默认是 UTC，而你的应用需要东八区（Asia/Shanghai），直接查 NOW() 就会差 8 小时。
别急着改系统时区——MySQL 有独立的时区控制链：启动参数 → 配置文件 → 会话变量。优先级从高到低，且部分设置重启才生效。
-
mysqld启动时加--default-time-zone='+08:00'或--default-time-zone='Asia/Shanghai'，但需确保系统已加载 tzdata（Ubuntu/Debian 要装tzdata包，CentOS 装glibc-common） - 更稳妥的方式是写进配置文件：
/etc/my.cnf或/etc/mysql/my.cnf的[mysqld]段下加一行：default-time-zone = '+08:00'
（推荐用偏移量，避免依赖系统时区数据库） - 改完必须重启
mysqld；验证方式：SELECT @@global.time_zone, @@session.time_zone;，两个都应显示+08:00 - 注意：即使全局设了，客户端连接仍可能被驱动或连接字符串覆盖（比如 JDBC 的
serverTimezone=GMT%2B8参数不能少）
哪些 my.cnf 参数对新部署实例最关键
刚装好的 MySQL 默认配置面向低负载测试环境，生产用必须调。不改可能很快遇到连接超限、查询慢、写入卡顿等问题。
-
max_connections：默认 151，小项目够用；中等业务建议 500–1000，但得配合 OS 层ulimit -n调高（否则 MySQL 启动报错Can't create thread） -
innodb_buffer_pool_size：InnoDB 缓存核心，物理内存的 50%–75% 是安全范围；设太大反而触发频繁 swap，观察Innodb_buffer_pool_wait_free状态变量是否持续 > 0 -
innodb_log_file_size：默认 48MB 太小，高写入场景建议 256–1024MB；但修改需停库、删旧日志、重启，不能热改 -
wait_timeout和interactive_timeout：默认 28800 秒（8 小时），长连接池未正确 close 会导致连接堆积；建议调成 300–600 秒，由应用层保活
为什么改了 my.cnf 却没生效
MySQL 加载配置的路径和顺序容易踩坑，尤其是多版本共存或用包管理器安装的实例。
- 运行
mysqld --verbose --help | grep "Default options"查真实读取路径（常见有/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf、$MYSQL_HOME/my.cnf） - 确认你编辑的是
[mysqld]段下的配置，不是[client]或[mysql]；后者只影响命令行工具，不影响服务端行为 - 检查语法：注释必须用
#或;，不能用//；布尔值写ON/OFF或1/0，不要写true/false - 改完配置后，用
mysqld --defaults-file=/etc/my.cnf --validate-config验证语法（MySQL 5.7.20+ 支持）；无效配置会导致启动失败且日志里只报“unknown variable”之类模糊提示
时区和参数调优后还要注意什么
最常被忽略的是权限与持久化细节：比如 default-time-zone 设为 Asia/Shanghai 后，如果系统 /usr/share/zoneinfo/Asia/Shanghai 文件被删或权限不对，MySQL 启动时不会报错，但实际按 UTC 运行；又比如 innodb_buffer_pool_size 调大后没同步调高 vm.swappiness，内存压力大会导致性能断崖式下跌。
上线前务必跑一次 SHOW VARIABLES LIKE '%time%'; 和 SHOW STATUS LIKE 'Innodb_buffer_pool%';，对照预期值核对。
