• by 京东技术专家 郝洪范

对于 Go CURD Boy 来说，相信 github.com/go-sql-driver/mysql 这个库都不会陌生。或许有些人可能没太留意，直接就复制粘贴了 import。比如我们使用 gorm 的时候，如果不加 _ "github.com/go-sql-driver/mysql" 的话，就会报：panic: sql: unknown driver "mysql" (forgotten import?)。基本上 Go 的 CURD 都离不开这个特别重要的库。

我们在开发 seata-go 时也使用了这个库。不过最近在使用 go-sql-driver/mysql 查询 mysql 的时候，就出现一个很有意思的 bug, 觉得有必要分享出来，以防止后来者再次踩坑。

1 问题详述

为了说明问题，这里不详述 seata-go 的相关代码，用一个单独的 demo 把问题详细描述清楚。

1.1 环境准备

在一个 MySQL 实例上准备如下环境：

CREATE TABLE `Test1` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `create_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

从这个 sql 语句中可以看出来， create_time 是 timestamp 类型，这里要特别留意 timestamp 这个类型。

现在插入一条数据，然后查看刚插入的数据的值。

insert into Test1 values (1, '2022-01-01 00:00:00')

查看下 msyql 当前的时区。请记好相关值，草蛇灰线，伏笔于此。

 show VARIABLES like '%time_zone%';

查询结果：

接下来使用 mysql unix_timestamp 查看 create_time 的时间戳

SELECT unix_timestamp(create_time) from Test1 where id = 1;

查询结果：

1.2 测试程序

有如下 demo 程序，示例使用 go-sql-driver 读取 create_time 的值：

package main

import (
	"database/sql"
	"fmt"
	"time"

    _ "github.com/go-sql-driver/mysql"
)

func main() {
  var user = "user"
  var pwd = "password"
  var dbName = "dbname"
    
  dsn := fmt.Sprintf("%s:%s@tcp(localhost:3306)/%s?timeout=100s&parseTime=true&interpolateParams=true", user, pwd, dbName)
  db, err := sql.Open("mysql", dsn)
  if err != nil {
    panic(err)
  }
  defer db.Close()

  rows, err := db.Query("select create_time from Test1 limit 1")
  if err != nil {
    panic(err)
  }
  for rows.Next() {
    t := time.Time{}
    rows.Scan(&t)
    fmt.Println(t)
    fmt.Println(t.Unix())
  }
}

我们运行个程序会输出下面的结果:

2022-01-01 00:00:00 +0000 UTC
1640995200

1.3 问题详述

发现问题所在了吗？有图如下，把结果放在一块，可以详细说明问题。

图中红色箭头指向的两个结果，用 go-sql-driver 读取的结果和在 MySQL 中用 unix_timestamp 获取的结果明显是不一样的。

2 问题探案

1.3 小节中最后示图可以看出，数据库中 create_time 的值 2022-01-01 00:00:00 是东八区的时间，也就是北京时间，这个时间对应的时间戳就是 1640966400。但是 go-sql-driver 示例程序读出来的却是 1640995200， 这是什么值？这是 0 时区的 2022-01-01 00:00:00。

对问题的直白描述就是：，MySQL 的 create_time 是 2022-01-01 00:00:00 +008，而读取到的是 2022-01-01 00:00:00 +000，他俩压根就不是一个值。

基本能看出来 bug 是如何发生的了。那就需要剖析下 go-sql-driver 源码，追查问题的根源。

2.1 go-sq-driver 源码分析

这里就不粘贴 "github.com/go-sql-driver/mysql" 的详细源码了，只贴关键的路径。

debug 的时候详细关注调用路径中红色的两个方块的内存中的值。

// https://github.com/go-sql-driver/mysql/blob/master/packets.go#L788-L798

func (rows *textRows) readRow(dest []driver.Value) error {
	
	// ... 

	// Parse time field
	switch rows.rs.columns[i].fieldType {
	case fieldTypeTimestamp,
		fieldTypeDateTime,
		fieldTypeDate,
		fieldTypeNewDate:
		if dest[i], err = parseDateTime(dest[i].([]byte), mc.cfg.Loc); err != nil {
			return err
		}
	}
}

func parseDateTime(b []byte, loc *time.Location) (time.Time, error) {
	const base = "0000-00-00 00:00:00.000000"
	switch len(b) {
	case 10, 19, 21, 22, 23, 24, 25, 26: // up to "YYYY-MM-DD HH:MM:SS.MMMMMM"

		year, err := parseByteYear(b)

		month := time.Month(m)

		day, err := parseByte2Digits(b[8], b[9])

		hour, err := parseByte2Digits(b[11], b[12])

		min, err := parseByte2Digits(b[14], b[15])

		sec, err := parseByte2Digits(b[17], b[18])

		// https://github.com/go-sql-driver/mysql/blob/master/utils.go#L166-L168
		if len(b) == 19 {
			return time.Date(year, month, day, hour, min, sec, 0, loc), nil
		}
	}
}

从这里基本上就能明白，go-sql-driver 把数据库读出来的 create_time timestamp 值当做一个字符串，然后按照 mysql timestamp 的标准格式 "0000-00-00 00:00:00.000000" 去解析，分别得到 year, month, day, hour, min, sec。最后依赖传入 time.Location 值，调用 go 系统库 time.Date() 再去生成对应的值。

这里表面看起来没有问题，其实这里严重依赖了传入的 time.Location。这个 time.Location 是如何得到的呢？进一步阅读源码，可以明显的看出来，是通过解析传入的 DSN 的 Loc 获取。其中关键代码是

https://github.com/go-sql-driver/mysql/blob/master/dsn.go#L467-L474

如果传入的 dsn 串不带 loc 时，Loc 就是 默认的 UTC 时区。

2.2 抽丝剥茧

回头看开头的程序，初始化 go-sql-driver 的 dsn 是 user:password@tcp(localhost:3306)/dbname?timeout=100s&parseTime=true&interpolateParams=true，该 dsn 里面并不包含 loc 信息，go-sql-driver 用使用了默认的 UTC 时区。 然后解析从 mysql 中获取的 timestamp 字段了，也就用默认的 UTC 时区去生成 Date，结果也就错了。

因此，问题的主要原因是：go-sql-driver 并没有按照数据库的时区去解析 timestamp 字段，而且依赖了开发者生成的 dsn 传入的 loc。当开发者传入的 loc 和 数据库的 time_zone 不匹配的时候，所有的 timestamp 字段都会解析错误。

有些人可能有疑问，如果 go-sql-driver 为什么不直接使用 mysql 的时区去解析 timestamp 呢？我们已经提了一个 issue https://github.com/go-sql-driver/mysql/issues/1379，商讨更好的解决方案。

3 最后结论

所以说，现阶段使用 go-sql-driver 的时候一定要特别注意，生成的 dsn 字符串一定要和数据的时区保持一致，不然的话就会导致 timestamp 字段解析错误。

细节处见真章，seata-go 社区认认真真做开源，做对用户负责任的高质量的项目。对项目感兴趣的朋友加入钉钉群 44816898，与我们交流技术 或者 下水参与开源，我们都欢迎。

4 参考文档

1. [The DATE, DATETIME, and TIMESTAMP Types]  https://dev.mysql.com/doc/refman/8.0/en/datetime.html
2. [mysql的timestamp会存在时区问题？]  https://juejin.cn/post/7007044908250824741
3. [is this is go-sql-driver bug]  https://github.com/go-sql-driver/mysql/issues/1379