在 Go 语言中使用 go-sql-driver/mysql（即 github.com/go-sql-driver/mysql）作为 MySQL 驱动时，连接字符串中的 loc 参数用于指定驱动在处理 DATETIME 和 TIMESTAMP 类型时所使用的 本地时区（Local Time Zone）。

一、loc 参数的作用

• loc 指定的是 Go 程序解析和格式化时间时使用的时区。
• 它 不会改变 MySQL 服务器本身的时区设置，而是影响 Go 驱动如何将数据库中的时间值转换为 Go 的 time.Time 类型，以及如何将 time.Time 写入数据库。

语法示例：

db, err := sql.Open("mysql", "user:password@tcp(127.0.0.1:3306)/dbname?loc=Asia%2FShanghai")

其中 Asia/Shanghai 是 IANA 时区名称，URL 编码后为 Asia%2FShanghai。

二、读取时间的行为（从 MySQL 到 Go）

1. 对于 DATETIME 字段：

• MySQL 的 DATETIME 没有时区信息，它只是字面值（如 '2025-11-20 12:00:00'）。
• 当 Go 驱动读取 DATETIME 时：
  • 如果设置了 loc=XXX，则会将该字面值 视为处于 loc 指定时区的时间，并转换为 time.Time（内部以 UTC 存储，但 Location 为 loc）。
  • 如果未设置 loc（默认），则使用 系统本地时区（即 time.Local）来解释这个字面值。

📌 举例：
数据库存储 2025-11-20 12:00:00
若 loc=UTC → Go 中得到 time.Time{2025-11-20 12:00:00 +0000 UTC}
若 loc=Asia/Shanghai → Go 中得到 time.Time{2025-11-20 12:00:00 +0800 CST}

2. 对于 TIMESTAMP 字段：

• MySQL 的 TIMESTAMP 存储时会自动转换为 UTC，读取时根据 当前会话的时区 转换回本地时间。
• 但 Go 驱动 不依赖 MySQL 会话时区，而是：
  • 先从 MySQL 获取到的是“已按会话时区转换后的字面值”（比如 '2025-11-20 20:00:00'），
  • 然后 Go 驱动再用 loc 参数指定的时区去解释这个字面值。

⚠️ 这里容易混淆！实际上，MySQL 在返回 TIMESTAMP 时已经根据 连接的时区 做了一次转换。而 Go 驱动的 loc 是对这个“已转换后的时间字符串”再次赋予时区语义。

✅ 最佳实践：确保 MySQL 连接时区与 Go 的 loc 一致，否则会出现双重转换错误。

你可以通过在连接串中同时设置 time_zone 来控制 MySQL 会话时区：

"root:pwd@tcp(127.0.0.1:3306)/db?loc=Asia%2FShanghai&time_zone=%2B08%3A00"

这样 MySQL 返回 TIMESTAMP 时已经是东八区时间，Go 驱动再用 Asia/Shanghai 解释，结果正确。

三、写入时间的行为（从 Go 到 MySQL）

当你把一个 time.Time 值写入数据库（无论是 DATETIME 还是 TIMESTAMP）：

1. Go 驱动会 先将 time.Time 转换为 loc 指定时区下的本地时间（即调用 .In(loc)）。
2. 然后把这个本地时间格式化为 'YYYY-MM-DD HH:MM:SS' 字符串，发送给 MySQL。

📌 举例：
Go 中有一个 time.Time 表示 2025-11-20T04:00:00Z（UTC 时间）
若 loc=Asia/Shanghai → 转换为 2025-11-20 12:00:00（CST）→ 写入数据库的值是 '2025-11-20 12:00:00'

• 对于 DATETIME：直接存这个字面值。
• 对于 TIMESTAMP：MySQL 会把这个字面值 当作当前会话时区的时间，再转成 UTC 存储。

⚠️ 所以如果 Go 的 loc 和 MySQL 的 time_zone 不一致，写入 TIMESTAMP 会出现偏差！

四、总结建议

五、关于连接会话时区

在 MySQL 中，连接会话的 time_zone（时区）如果没有显式设置，默认值取决于服务器的全局配置。

一、默认行为

当你建立一个新的 MySQL 连接（会话）时：

• 会话变量 time_zone 的初始值 = 全局变量 time_zone 的值
• 而 全局变量 time_zone 的默认值通常是 'SYSTEM'

你可以通过以下 SQL 查看：

-- 查看当前会话时区
SELECT @@session.time_zone;

-- 查看全局时区设置
SELECT @@global.time_zone;

二、'SYSTEM' 是什么意思？

当 time_zone = 'SYSTEM' 时：

• MySQL 会使用 数据库服务器所在操作系统的系统时区 来解释和转换 TIMESTAMP 值。
• 例如：如果 MySQL 运行在一台时区为 Asia/Shanghai 的 Linux 服务器上，那么 SYSTEM 就等价于 +08:00。

⚠️ 注意：SYSTEM 时区 不能用于命名时区（如 'Asia/Shanghai'）的功能，比如 CONVERT_TZ() 函数在 SYSTEM 下可能无法正确处理夏令时或历史时区变更，除非你已加载了 MySQL 的时区表。

三、对 Go 程序的影响（结合 loc 参数）

假设你的 Go 程序连接 MySQL 时 没有设置 time_zone 参数，那么：

• MySQL 会话时区 = SYSTEM（即服务器 OS 时区）
• 当你读写 TIMESTAMP 字段时，MySQL 会按这个系统时区做自动转换
• 但 Go 驱动的 loc 参数独立工作 —— 它决定如何解释从 MySQL 拿到的时间字符串

👉 如果 Go 的 loc 和 MySQL 的 SYSTEM 时区不一致，就会出现时间偏差！

四、最佳实践建议

为了避免不确定性，强烈建议在连接字符串中显式指定时区：

// 示例：统一使用东八区
"username:password@tcp(127.0.0.1:3306)/dbname?loc=Asia%2FShanghai&time_zone=%2B08%3A00"

或者统一用 UTC：

"username:password@tcp(127.0.0.1:3306)/dbname?loc=UTC&time_zone=%2B00%3A00"

这样可以：

• 避免依赖服务器的系统时区（便于部署一致性）
• 确保 Go 和 MySQL 对时间的解释完全一致
• 减少 TIMESTAMP 字段因双重转换导致的错误

五、补充：如何查看 MySQL 系统时区？

在 MySQL 中执行：

SELECT @@system_time_zone;

这会返回操作系统报告的时区缩写（如 CST、UTC），但注意它 只是一个标识符，不代表完整 IANA 时区规则。

✅ 总结：

如有具体部署环境（如 Docker、云数据库），也可以进一步分析其默认时区行为。

六、参考文档

• go-sql-driver/mysql GitHub
• MySQL 官方文档关于 TIMESTAMP 和时区