PHP时区设置不影响MySQL存储行为，MySQL存取时间取决于其自身time_zone配置及字段类型（TIMESTAMP自动时区转换，DATETIME不转换），推荐统一用UTC作为中间标准。
PHP date_default_timezone_set() 不影响 MySQL 存储行为
PHP 设置时区只改变 PHP 自身的时间函数输出（如 date()、strtotime()），对 MySQL 的 INSERT 或 UPDATE 操作本身没有强制干预。MySQL 是否存入 UTC、本地时间，取决于它自己的配置和你写的 SQL —— 比如用 NOW() 还是 UTC_TIMESTAMP()，而不是 PHP 时区。
常见错误现象：date('Y-m-d H:i:s') 输出北京时间，但数据库里查出来时间“少8小时”，其实是 MySQL 服务端默认用系统时区（比如 UTC）解析了你传进去的字符串，而你没显式指定时区上下文。
- PHP 写入时间建议统一用
date('Y-m-d H:i:s')格式字符串 + 明确时区语义（比如“这是东八区时间”），不要依赖 MySQL 自动转换 - 避免在 SQL 中直接写
NOW()，改用CONVERT_TZ(NOW(), '+00:00', '+08:00')或更稳妥的UTC_TIMESTAMP()+ 应用层换算 - MySQL 5.7+ 可通过
SET time_zone = '+08:00'临时会话设置，但不推荐全局依赖，容易被连接池复用污染
MySQL time_zone 配置决定 NOW() 和 SYSDATE() 返回值
MySQL 的 time_zone 系统变量控制所有依赖系统时间的函数行为。它和操作系统时区、PHP 时区完全无关，是独立配置项。查当前值用 SELECT @@global.time_zone, @@session.time_zone;。
使用场景：跨服务器部署时，DBA 可能将生产库设为 SYSTEM（继承系统时区），而测试库设为 +00:00，导致同样 PHP 代码在两地表现不一致。
立即学习“PHP免费学习笔记（深入）”；
-
@@global.time_zone是启动时读取的，修改需SET GLOBAL time_zone = '+08:00'并重启或重连（部分版本不支持动态改 global） -
@@session.time_zone可随时改，但只对当前连接有效；PDO 连接默认不会自动同步 PHP 时区，得手动执行SET time_zone = '+08:00' - 用
TIMESTAMP类型字段时，MySQL 会把写入值按 session time_zone 转成 UTC 存，读出时再转回；DATETIME则原样存储，不做任何转换 —— 这是关键区别
PHP 与 MySQL 时区同步的最小可靠方案
不追求“全自动同步”，而是明确切割责任：PHP 负责生成带时区信息的时间值，MySQL 负责无歧义存储。最简路径是绕过双方时区博弈，用 UTC 作为唯一中间语言。
实操建议：
- PHP 全局设
date_default_timezone_set('UTC')，所有date()输出都是 UTC 字符串 - MySQL 全局
time_zone = '+00:00'，确保NOW()也是 UTC - 前端显示时，由 JS 或模板引擎按用户所在时区格式化（比如用
Intl.DateTimeFormat），PHP 层不参与时区渲染 - 已有 DATETIME 字段且存的是本地时间？别硬改配置，加个迁移脚本：用
ADDTIME(col, '-08:00')批量转成 UTC 值再更新字段
CONVERT_TZ() 在 WHERE 条件中可能让索引失效
用 CONVERT_TZ(created_at, '+00:00', '+08:00') >= '2024-01-01' 这类写法，MySQL 无法使用 created_at 上的索引，因为字段被函数包裹了。性能隐患比时区错乱更隐蔽。
正确做法永远优先把比较逻辑移到应用层：PHP 算好 UTC 时间范围，再生成 WHERE created_at BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 23:59:59' 这样的纯字段查询。
- 如果必须用
CONVERT_TZ，仅限于 SELECT 投影层做展示转换，绝不放进 WHERE / ORDER BY / GROUP BY - MySQL 8.0+ 支持函数索引，可建
CREATE INDEX idx_created_utc ON tbl (CONVERT_TZ(created_at, '+00:00', '+08:00'))，但维护成本高，不推荐作为首选 - 跨时区统计报表？直接在 PHP 里用
DateTimeZone对齐时间轴，比在 SQL 里反复转换更可控
真正麻烦的不是设对一个 date_default_timezone_set()，而是 DATETIME 字段里混着不同时区含义的数据 —— 有的是 PHP 本地时间字符串，有的是 MySQL 自动转的 UTC，还有的是前端传来的 ISO 8601 带偏移。这种数据一旦入库，就很难靠配置挽回。
