NOW()返回语句开始时间，SYSDATE()返回函数调用瞬间时间，故在耗时操作中二者结果可能不同；CURRENT_TIMESTAMP与NOW()行为一致，但建表默认值必须用CURRENT_TIMESTAMP。
MySQL 中 NOW() 和 SYSDATE() 返回值为什么有时不一样
因为 NOW() 返回语句开始执行时的时间，而 SYSDATE() 返回函数实际被调用时的时间。在包含多条语句或耗时操作的事务中，两者可能产生秒级甚至毫秒级差异。
- 常见错误现象：
SELECT NOW(), SLEEP(2), NOW();两次NOW()结果相同；但SELECT SYSDATE(), SLEEP(2), SYSDATE();两次结果相差约 2 秒 - 使用场景：
NOW()更适合记录“事务起始时间”，比如插入日志表时统一打上同一时间戳；SYSDATE()适合需要精确到调用瞬间的场景，如审计操作耗时、生成唯一性时间片段 - 性能影响：二者开销几乎无差别，但
SYSDATE()是非确定性函数（non-deterministic），在基于语句的复制（SBR）模式下可能导致主从不一致，MySQL 8.0+ 默认已切换为 ROW 模式，影响变小但仍需留意
在 INSERT 或 UPDATE 里该用 NOW() 还是 CURRENT_TIMESTAMP
CURRENT_TIMESTAMP 是标准 SQL 写法，NOW() 是 MySQL 的同义词，二者在默认情况下行为完全一致——都取语句开始时间，且都支持小数秒精度（如 CURRENT_TIMESTAMP(3)）。
- 参数差异：
NOW(6)和CURRENT_TIMESTAMP(6)都能返回微秒级时间；但SYSDATE(6)同样支持，而老版本 MySQL 对SYSDATE()的精度支持略晚于NOW() - 容易踩的坑：建表时定义列默认值用
DEFAULT CURRENT_TIMESTAMP，不能写成DEFAULT NOW()（语法报错）；同样，ON UPDATE CURRENT_TIMESTAMP也不能替换成ON UPDATE NOW() - 兼容性考虑：如果未来可能迁移到 PostgreSQL 或 SQLite，优先用
CURRENT_TIMESTAMP，它在各数据库中语义更稳定
为什么在存储过程中调用 SYSDATE() 仍可能和预期不符
因为存储过程内部的执行顺序、是否启用查询缓存、以及是否在事务中嵌套了其他耗时逻辑，都会让 SYSDATE() 的“调用瞬间”变得难以预测。
- 常见错误现象：在一个循环里反复调用
SYSDATE()记录步骤时间，结果发现相邻两次只差几毫秒，但某次突然跳变几百毫秒——很可能是遇到了磁盘 I/O 或锁等待，函数调用被延迟了 - 实操建议：如需高精度计时，不要依赖
SYSDATE()做差值计算；改用客户端语言（如 Python 的time.time()）或 MySQL 8.0+ 的performance_schema事件追踪 - 另一个坑：
SYSDATE()受会话时区影响（和NOW()一样），但如果你在存储过程中临时修改了时区（SET time_zone = '+05:30'），后续SYSDATE()结果会立刻响应变化，这点比某些缓存时间函数更“敏感”
如何安全地在复制环境中使用 SYSDATE()
只要不是在基于语句的复制（SBR）模式下直接用于 INSERT/UPDATE 的 VALUES 部分，就基本安全。但一旦涉及主从一致性要求高的场景，就得绕开它。
- 使用场景限制：禁止在主库执行
INSERT INTO t VALUES (SYSDATE());并期望从库得到相同值；这种语句在 SBR 下会导致从库写入不同时间，破坏数据一致性 - 替代方案：用
NOW()+ 显式传参（如应用层生成时间戳后作为参数传入）；或者改用DEFAULT CURRENT_TIMESTAMP定义列，由 MySQL 自动填充 - 检查当前模式：运行
SELECT @@binlog_format;，若返回STATEMENT，则应避免在 DML 中直接使用SYSDATE()；返回ROW或MIXED则风险较低
事情说清了就结束。时间函数看着简单，但一牵扯到复制、事务、精度和跨系统迁移，细节就藏得很深。
