LOCALTIME 返回 MySQL 服务器系统时区的当前日期时间，与 NOW() 完全等价，不受客户端时区影响；其值取决于 @@global.time_zone 或底层系统时区，而非用户本地设备时区。
LOCALTIME 在 MySQL 中确实能返回当前时间，但它返回的是服务器系统时区的时间，不是“你本地电脑”的时间——这点很多人一开始会误解。
LOCALTIME 是什么，和 NOW() 有什么区别？
LOCALTIME 是 NOW() 的同义词，两者完全等价，都返回服务器当前的日期和时间（DATETIME 类型），且都受 MySQL 服务端时区设置影响，不受客户端连接时区参数干扰。
-
LOCALTIME和LOCALTIME()都合法，括号可选 - 它不读取你的笔记本电脑或浏览器所在时区，只看 MySQL 服务进程运行的操作系统时区
- 如果服务器时区是
UTC，LOCALTIME就返回 UTC 时间，哪怕你在北京连上去也一样
怎么确认 LOCALTIME 真正返回的是哪个时区的时间？
别猜，直接查。执行这两条语句对比：
SELECT LOCALTIME(), @@global.time_zone, @@session.time_zone;
输出中：
-
@@global.time_zone显示 MySQL 全局时区（可能是SYSTEM，即继承系统） -
@@session.time_zone显示当前连接的时区（默认继承 global，但可被SET time_zone = '+8:00'修改） - 注意：
LOCALTIME不受@@session.time_zone影响，只认@@global.time_zone或底层系统时区
想用“本地”时间但服务器在 UTC，怎么办？
如果你的应用逻辑依赖东八区时间，而 MySQL 服务器跑在 UTC 时区，LOCALTIME 就不能直接用。常见做法有：
- 改服务器时区：修改
/etc/my.cnf加default-time-zone='+08:00'并重启 mysqld（最彻底，但需运维权限） - 临时转换：用
CONVERT_TZ(LOCALTIME(), '+00:00', '+08:00')——但要求 MySQL 时区表已加载（mysql_tzinfo_to_sql导入过） - 应用层处理：把
LOCALTIME当作 UTC 时间接收，在代码里转成本地时区（更可控，推荐）
LOCALTIME 在 INSERT/UPDATE 里容易踩的坑
写入时间字段时，别想当然认为 LOCALTIME 能自动适配用户时区：
- 用
DEFAULT LOCALTIME建表，所有插入都按服务器时区记，跨地域部署时可能混乱 - 如果字段类型是
TIMESTAMP，它本身会自动转成 UTC 存储、按 session 时区读出；但LOCALTIME插入进去的仍是原始服务器时间，和TIMESTAMP的行为不一致，混用易出错 - 建议统一用
TIMESTAMP+ 显式SET time_zone控制，比依赖LOCALTIME更可靠
真正关键的不是函数名里有没有 “LOCAL”，而是你清楚知道 MySQL 进程在哪个时区运行，以及你的数据需要按什么标准解释——否则 LOCALTIME 返回的永远只是服务器眼里的“现在”。
