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;
这条语句会将
id为
123的记录的
updated_at字段更新为当前的日期时间。
在我看来，
NOW()的简洁性是它最大的优势。它省去了你在应用层处理时间格式化、时区转换的麻烦，直接在数据库层面完成了这一步，这对于保持数据一致性非常有用。
NOW()
与SYSDATE()
、CURDATE()
、CURTIME()
等函数有何不同？
这几个函数在功能上确实有些相似，但它们之间存在一些细微但关键的区别，特别是在处理时间精确度和上下文方面。理解这些差异，能帮助我们避免一些潜在的问题。
NOW()
: 这个函数返回的是语句开始执行时的日期和时间。也就是说，如果你在一个复杂的查询或存储过程中多次调用
NOW()，它在同一个语句的执行过程中会返回相同的时间戳。这对于确保数据一致性非常重要，比如在事务中，你希望所有操作都基于同一个“当前时间”。它的格式是
YYYY-MM-DD HH:MM:SS。
SYSDATE()
:
SYSDATE()则返回函数执行时的日期和时间。这意味着，如果在同一个语句中多次调用
SYSDATE()，由于函数每次执行都会重新获取系统时间，你可能会得到略微不同的时间戳。在某些对时间精度要求极高或需要反映实时系统时间的场景下，它可能有用，但通常在复制（replication）或审计日志中，
NOW()因其一致性而被更广泛推荐。它也返回
YYYY-MM-DD HH:MM:SS格式。
CURDATE()
: 顾名思义，
CURDATE()只返回当前的日期，格式是
YYYY-MM-DD。它不包含时间部分。当你只需要记录日期，比如用户的生日、事件发生的日期等，
CURDATE()就非常合适。
CURTIME()
: 类似地，
CURTIME()只返回当前的时间，格式是
HH:MM:SS。当你只需要时间部分，例如记录某个事件发生的小时分钟秒，
CURTIME()是理想选择。
我个人在实际开发中，如果不是有特殊需求，通常会优先使用
NOW()，因为它在事务和复杂语句中的行为更可预测，能有效避免时间戳不一致带来的困扰。
示例：
SELECT
NOW() AS 'NOW_Function',
SYSDATE() AS 'SYSDATE_Function',
CURDATE() AS 'CURDATE_Function',
CURTIME() AS 'CURTIME_Function';你可以尝试连续执行几次，观察
NOW()和
SYSDATE()在极短时间内可能出现的差异。
如何在NOW()
函数获取的时间上进行加减操作？
对日期和时间进行加减操作是数据库应用中非常常见的需求，比如计算某个事件的截止日期、过期时间，或者查询未来某个时间段的数据。MySQL提供了非常强大的函数来处理这些需求，其中
DATE_ADD()和
DATE_SUB()是核心。
这两个函数都接受三个参数：一个日期时间值、一个
INTERVAL关键字以及一个时间间隔。
DATE_ADD(date, INTERVAL expr unit): 用于在指定日期时间上增加一个时间间隔。
DATE_SUB(date, INTERVAL expr unit): 用于在指定日期时间上减去一个时间间隔。
expr是你想要增加或减少的数值，而
unit则指定了时间单位，比如
DAY、
HOUR、
MINUTE、
SECOND、
MONTH、
YEAR等等。
增加时间示例：
假设你想计算从现在开始的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';这些函数非常灵活，几乎可以满足所有日期时间加减的场景。我个人觉得，掌握
INTERVAL的各种
unit用法是关键，比如
YEAR_MONTH、
DAY_HOUR等复合单位，它们能让你更精确地控制时间间隔。
NOW()
函数在不同时区下表现如何？
时区问题在跨国应用或分布式系统中是一个常见的“坑”，
NOW()函数也不例外。理解
NOW()如何与MySQL的时区设置交互，对于避免数据混乱至关重要。
NOW()函数返回的时间是基于MySQL服务器的当前会话时区（
@@session.time_zone）的。如果你的MySQL服务器默认时区是UTC，那么
NOW()返回的就是UTC时间；如果服务器默认时区是北京时间（CST），那么
NOW()返回的就是北京时间。
一个常见的误区是，认为
NOW()会智能地根据客户端的地理位置返回时间。但实际上，它只认服务器或当前会话的时区设置。
可能出现的问题：
-
服务器时区与应用期望时区不一致： 比如你的服务器设置在欧洲，而你的应用用户主要在中国。如果直接用
NOW()记录时间，那么数据库中存储的时间就会是欧洲时间，而不是用户期望的北京时间。 数据迁移或复制问题： 当数据从一个时区设置的服务器迁移到另一个时区设置的服务器时，如果没有正确处理，时间字段可能会出现偏差。
解决方案和建议：
统一服务器时区为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'
使用UTC_TIMESTAMP()
函数： 如果你希望明确地获取UTC时间，而不受服务器会话时区的影响，可以使用
UTC_TIMESTAMP()。
SELECT NOW(), UTC_TIMESTAMP();
UTC_TIMESTAMP()始终返回UTC时间，这在很多场景下比
NOW()更可靠，尤其是在处理日志或需要跨时区比较时间时。
在应用层处理时区转换： 如果数据库中存储的是UTC时间，那么在将数据展示给用户时，由应用层负责将UTC时间转换为用户所在的时区。这是最灵活和健壮的做法。
使用CONVERT_TZ()
函数： MySQL也提供了
CONVERT_TZ(dt, from_tz, to_tz)函数，可以在数据库内部进行时区转换。
-- 假设NOW()返回的是UTC时间，我们想转换为北京时间 SELECT CONVERT_TZ(NOW(), '+00:00', '+08:00'); -- 或者 SELECT CONVERT_TZ(UTC_TIMESTAMP(), 'UTC', 'Asia/Shanghai');
需要注意的是，要使用
CONVERT_TZ()，你的MySQL服务器必须加载了时区信息表（
mysql.time_zone）。
在我看来，处理时区最核心的原则就是“统一存储，按需转换”。尽量在数据库中存储统一的、无歧义的时间（如UTC），然后在展示或计算时才进行时区转换。这能大大减少因时区问题导致的逻辑错误。
