如何获取当前SQL系统时间_掌握NOW与CURRENT

NOW()和CURRENT_TIMESTAMP()在MySQL中功能相似但不完全等价：前者是MySQL专有别名，后者符合SQL标准；语法、默认值定义、自动更新、精度支持及时区行为均有差异。

如何获取当前sql系统时间_掌握now与current_timestamp

MySQL 里 `NOW()` 和 `CURRENT_TIMESTAMP()` 真的等价吗？

绝大多数情况下，它们返回相同结果，但不是“完全等价”——CURRENT_TIMESTAMP() 是标准 SQL 的写法，而 NOW() 是 MySQL 的别名函数；在严格模式或跨数据库迁移时，用 CURRENT_TIMESTAMP() 更稳妥。

常见错误现象：INSERT INTO log (ts) VALUES (NOW);（漏了括号）→ 报错 ERROR 1064；MySQL 把没括号的 NOW 当作列名或标识符处理，必须写成 NOW() 或 CURRENT_TIMESTAMP()。

两者都返回当前会话时区下的时间戳（精度到秒，除非显式声明毫秒）
作为默认值定义字段时，CURRENT_TIMESTAMP（无括号）是合法语法，NOW() 则不被允许
如果需要自动更新时间，只能用 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，NOW() 不支持该语法

想带毫秒？别只写 `CURRENT_TIMESTAMP()`

默认调用不带精度参数时，CURRENT_TIMESTAMP() 和 NOW() 都只返回秒级时间，比如 2024-05-22 14:30:45。要毫秒，必须显式指定精度。

使用场景：日志追踪、高并发幂等判断、调试时需区分快速连续操作。

CURRENT_TIMESTAMP(3) → 返回带 3 位毫秒的时间，如 2024-05-22 14:30:45.123
NOW(6) → 同样有效，支持最多 6 位微秒，但注意：底层存储类型得是 DATETIME(6) 或 TIMESTAMP(6)，否则精度被截断
性能影响极小，但字段定义精度越高，索引体积略增，写入时多一次截断/舍入计算

时区搞错导致时间“凭空偏移”？查 `@@time_zone` 比猜强

你看到的 NOW() 结果，取决于会话时区，不是服务器系统时区。很多线上问题就卡在这儿：应用连的是 UTC 时区的实例，但开发本地连的是 +08:00，同一句 SQL 返回值差 8 小时。

错误现象：定时任务在凌晨 2 点触发失败，日志里查 NOW() 却显示是凌晨 10 点。

执行 SELECT @@time_zone; 查当前会话时区（常见值：SYSTEM、+00:00、Asia/Shanghai）
临时修改会话时区：SET time_zone = '+08:00';，之后 NOW() 才按东八区算
建表时若用 TIMESTAMP 类型，值会自动按会话时区转存/读取；DATETIME 则原样存储，不转换——这点常被忽略

在 INSERT 或 DEFAULT 中直接用 `CURRENT_TIMESTAMP` 要小心括号

这是最易踩的语法坑：在列定义里写默认值，CURRENT_TIMESTAMP 可以不带括号；但一旦加了括号，MySQL 5.6+ 会报错 ERROR 1067: Invalid default value。

示例对比：

CREATE TABLE events (
  id INT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,          -- ✅ 合法
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- ✅ 合法
  bad_col TIMESTAMP DEFAULT CURRENT_TIMESTAMP()            -- ❌ 报错
);