NOW()函数用于获取当前日期和时间，格式为YYYY-MM-DD HH:MM:SS，常用于SELECT、INSERT和UPDATE语句中记录数据操作时间。

NOW()函数在MySQL中就是用来获取当前日期和时间的，它会返回一个标准格式的日期时间字符串，比如YYYY-MM-DD HH:MM:SS。这几乎是数据库操作中最常用、也最基础的时间函数之一了。

解决方案

使用NOW()函数获取当前时间非常直接。你可以在SELECT语句中单独使用它来查看当前的日期和时间，也可以在INSERT或UPDATE语句中将其作为某个日期时间字段的值。

获取当前日期时间：

SELECT NOW();

执行这条语句，你就会得到类似2023-10-27 10:30:45这样的结果，具体取决于你执行查询的精确时间。

在INSERT语句中使用：

当你需要记录数据创建的时间时，NOW()就显得尤为方便。

INSERT INTO your_table (column1, column2, created_at) VALUES ('value1', 'value2', NOW());

这样，created_at字段就会自动填充为数据插入时的当前日期和时间。

在UPDATE语句中使用：

更新记录的修改时间也是一个常见场景。

UPDATE your_table SET updated_at = NOW() WHERE id = 123;

这条语句会将YYYY-MM-DD HH:MM:SS1为YYYY-MM-DD HH:MM:SS2的记录的YYYY-MM-DD HH:MM:SS3字段更新为当前的日期时间。

在我看来，NOW()的简洁性是它最大的优势。它省去了你在应用层处理时间格式化、时区转换的麻烦，直接在数据库层面完成了这一步，这对于保持数据一致性非常有用。

NOW()与YYYY-MM-DD HH:MM:SS6、YYYY-MM-DD HH:MM:SS7、YYYY-MM-DD HH:MM:SS8等函数有何不同？

这几个函数在功能上确实有些相似，但它们之间存在一些细微但关键的区别，特别是在处理时间精确度和上下文方面。理解这些差异，能帮助我们避免一些潜在的问题。

• NOW(): 这个函数返回的是语句开始执行时的日期和时间。也就是说，如果你在一个复杂的查询或存储过程中多次调用NOW()，它在同一个语句的执行过程中会返回相同的时间戳。这对于确保数据一致性非常重要，比如在事务中，你希望所有操作都基于同一个“当前时间”。它的格式是YYYY-MM-DD HH:MM:SS。

• YYYY-MM-DD HH:MM:SS6: YYYY-MM-DD HH:MM:SS6则返回函数执行时的日期和时间。这意味着，如果在同一个语句中多次调用YYYY-MM-DD HH:MM:SS6，由于函数每次执行都会重新获取系统时间，你可能会得到略微不同的时间戳。在某些对时间精度要求极高或需要反映实时系统时间的场景下，它可能有用，但通常在复制（replication）或审计日志中，NOW()因其一致性而被更广泛推荐。它也返回YYYY-MM-DD HH:MM:SS格式。

• YYYY-MM-DD HH:MM:SS7: 顾名思义，YYYY-MM-DD HH:MM:SS7只返回当前的日期，格式是NOW()9。它不包含时间部分。当你只需要记录日期，比如用户的生日、事件发生的日期等，YYYY-MM-DD HH:MM:SS7就非常合适。

• YYYY-MM-DD HH:MM:SS8: 类似地，YYYY-MM-DD HH:MM:SS8只返回当前的时间，格式是SELECT3。当你只需要时间部分，例如记录某个事件发生的小时分钟秒，YYYY-MM-DD HH:MM:SS8是理想选择。

我个人在实际开发中，如果不是有特殊需求，通常会优先使用NOW()，因为它在事务和复杂语句中的行为更可预测，能有效避免时间戳不一致带来的困扰。

示例：

SELECT     NOW() AS 'NOW_Function',     SYSDATE() AS 'SYSDATE_Function',     CURDATE() AS 'CURDATE_Function',     CURTIME() AS 'CURTIME_Function';

你可以尝试连续执行几次，观察NOW()和YYYY-MM-DD HH:MM:SS6在极短时间内可能出现的差异。

如何在NOW()函数获取的时间上进行加减操作？

对日期和时间进行加减操作是数据库应用中非常常见的需求，比如计算某个事件的截止日期、过期时间，或者查询未来某个时间段的数据。MySQL提供了非常强大的函数来处理这些需求，其中SELECT9和INSERT0是核心。

麦当秀MindShow AiPPT

麦当秀｜MINDSHOW是一款百万用户正在使用的三分钟生成一份PPT的AI应用系统。它利用引领前沿的人工智能技术，能够自动完成演示内容的设计。

224

查看详情

这两个函数都接受三个参数：一个日期时间值、一个INSERT1关键字以及一个时间间隔。

• INSERT2: 用于在指定日期时间上增加一个时间间隔。
• INSERT3: 用于在指定日期时间上减去一个时间间隔。

INSERT4是你想要增加或减少的数值，而INSERT5则指定了时间单位，比如INSERT6、INSERT7、INSERT8、INSERT9、UPDATE0、UPDATE1等等。

增加时间示例：

假设你想计算从现在开始的3天后、1小时后、2个月后的时间：

SELECT     NOW() AS 'CurrentTime',     DATE_ADD(NOW(), INTERVAL 3 DAY) AS 'ThreeDaysLater',     DATE_ADD(NOW(), INTERVAL 1 HOUR) AS 'OneHourLater',     DATE_ADD(NOW(), INTERVAL 2 MONTH) AS 'TwoMonthsLater',     DATE_ADD(NOW(), INTERVAL '1 10:00:00' DAY_SECOND) AS 'OneDayTenHoursLater'; -- 复合单位

减少时间示例：

如果你想知道1周前、30分钟前的时间：

SELECT     NOW() AS 'CurrentTime',     DATE_SUB(NOW(), INTERVAL 1 WEEK) AS 'OneWeekAgo',     DATE_SUB(NOW(), INTERVAL 30 MINUTE) AS 'ThirtyMinutesAgo';

这些函数非常灵活，几乎可以满足所有日期时间加减的场景。我个人觉得，掌握INSERT1的各种INSERT5用法是关键，比如UPDATE4、UPDATE5等复合单位，它们能让你更精确地控制时间间隔。

NOW()函数在不同时区下表现如何？

时区问题在跨国应用或分布式系统中是一个常见的“坑”，NOW()函数也不例外。理解NOW()如何与MySQL的时区设置交互，对于避免数据混乱至关重要。

NOW()函数返回的时间是基于MySQL服务器的当前会话时区（2023-10-27 10:30:450）的。如果你的MySQL服务器默认时区是UTC，那么NOW()返回的就是UTC时间；如果服务器默认时区是北京时间（CST），那么NOW()返回的就是北京时间。

一个常见的误区是，认为NOW()会智能地根据客户端的地理位置返回时间。但实际上，它只认服务器或当前会话的时区设置。

可能出现的问题：

1. 服务器时区与应用期望时区不一致： 比如你的服务器设置在欧洲，而你的应用用户主要在中国。如果直接用NOW()记录时间，那么数据库中存储的时间就会是欧洲时间，而不是用户期望的北京时间。
2. 数据迁移或复制问题： 当数据从一个时区设置的服务器迁移到另一个时区设置的服务器时，如果没有正确处理，时间字段可能会出现偏差。

解决方案和建议：

• 统一服务器时区为UTC： 这是我最推荐的做法。将MySQL服务器的时区设置为UTC（协调世界时）。UTC是一个全球标准时间，不涉及夏令时等复杂问题。这样，数据库中存储的时间都是统一的UTC时间，应用层再根据用户的时区进行转换显示。

  -- 查看当前全局和会话时区 SELECT @@global.time_zone, @@session.time_zone; -- 设置全局时区（需要重启MySQL服务生效） SET GLOBAL time_zone = '+00:00'; -- 或 'UTC' -- 设置会话时区（当前连接有效） SET time_zone = '+00:00'; -- 或 'UTC'

• 使用2023-10-27 10:30:455函数： 如果你希望明确地获取UTC时间，而不受服务器会话时区的影响，可以使用2023-10-27 10:30:455。

  SELECT NOW(), UTC_TIMESTAMP();

  2023-10-27 10:30:455始终返回UTC时间，这在很多场景下比NOW()更可靠，尤其是在处理日志或需要跨时区比较时间时。

• 在应用层处理时区转换： 如果数据库中存储的是UTC时间，那么在将数据展示给用户时，由应用层负责将UTC时间转换为用户所在的时区。这是最灵活和健壮的做法。

• 使用2023-10-27 10:30:459函数： MySQL也提供了INSERT0函数，可以在数据库内部进行时区转换。

  -- 假设NOW()返回的是UTC时间，我们想转换为北京时间 SELECT CONVERT_TZ(NOW(), '+00:00', '+08:00'); -- 或者 SELECT CONVERT_TZ(UTC_TIMESTAMP(), 'UTC', 'Asia/Shanghai');

  需要注意的是，要使用2023-10-27 10:30:459，你的MySQL服务器必须加载了时区信息表（INSERT2）。

在我看来，处理时区最核心的原则就是“统一存储，按需转换”。尽量在数据库中存储统一的、无歧义的时间（如UTC），然后在展示或计算时才进行时区转换。这能大大减少因时区问题导致的逻辑错误。