17370845950

MySQL建表时用DATETIME配DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP最稳妥，PHP插入时不传时间字段由数据库自动生成，更新时显式设updated_at=NOW()并统一时区可避免8小时偏差。

MySQL建表时如何加 created_at 和 updated_at 时间戳字段

直接在建表语句里用 TIMESTAMP 或 DATETIME 配合默认值和自动更新最稳妥，避免 PHP 层拼时间字符串出错。

• TIMESTAMP 自动时区转换（存 UTC，查本地时区），DATETIME 原样存储，无时区处理 —— 若项目跨时区且依赖数据库自动维护，优先选 TIMESTAMP
• MySQL 5.6.5+ 支持 DATETIME 的 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP，不必强求 TIMESTAMP
• 一个表最多只能有一个 TIMESTAMP 字段带 CURRENT_TIMESTAMP 默认值（旧版本限制），DATETIME 没这限制

CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50),
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

PHP插入数据时不手动传时间戳的几种写法

让数据库自己填时间，PHP 就别碰 created_at / updated_at 字段，否则容易覆盖、不一致或触发时区混乱。

• INSERT 语句里完全不提这两个字段：INSERT INTO users (name) VALUES ('Alice')
• 用 PDO 时，绑定参数也跳过它们：$stmt->execute(['name' => 'Bob'])
• Laravel Eloquent 默认自动处理，但需确认模型里没显式赋值给 created_at —— 检查是否误写了 $model->created_at = date('Y-m-d H:i:s')

PHP更新数据时正确触发 updated_at 自动更新

关键不是 PHP 怎么写，而是 SQL 语句有没有真正“修改”到行 —— 如果 SET 的字段值和原值一样，MySQL 8.0+ 默认不会触发 ON UPDATE（除非开启 sql_mode=TRADITIONAL 或改用 UPDATE ... SET updated_at = NOW() 显式更新）。

• 安全做法：更新时显式设置 updated_at = NOW()，尤其用于软删除、状态切换等可能值不变的场景
• 用 PDO 执行：$pdo->prepare("UPDATE users SET status = ?, updated_at = NOW() WHERE id = ?")->execute([$status, $id])
• ORM 如 ThinkPHP 的 save() 默认会写 updated_at，但 CodeIgniter 3 的 update() 不会，得自己加 'updated_at' => date('Y-m-d H:i:s')

时区不一致导致时间戳看起来“慢8小时”的原因和修复

不是 PHP 错，也不是 MySQL 错，是两边时区没对齐。常见组合：PHP 设了 date_default_timezone_set('Asia/Shanghai')，但 MySQL 的 time_zone 还是 +00:00。

• 查 MySQL 当前时区：SELECT @@global.time_zone, @@session.time_zone;
• 临时改会话时区：SET time_zone = '+08:00';（仅当前连接有效）
• 永久生效要改 MySQL 配置文件 my.cnf，加 default-time-zone = '+08:00' 并重启
• 更推荐统一用 UTC 存储，PHP 层用 DateTime 转换显示 —— 避免后期国际化踩坑

实际开发中，最常被忽略的是更新语句未真正变更数据却指望 updated_at 变；其次是 MySQL 时区和 PHP 时区各自设了一套，结果日志里时间对不上。这两处一错，排查起来比加字段本身花的时间多得多。