使用go-sql-driver.mysql包報錯unexpected EOF

使用go-sql-driver/mysql包報錯，信息以下：

[mysql] 2016/12/29 12:05:34 packets.go:33: unexpected EOF
[mysql] 2016/12/29 12:05:34 packets.go:124: write tcp 10.94.104.39:42418->10.94.104.39:3306: write: broken pipe

下面是輸出錯誤信息的代碼：

func (mc *mysqlConn) readPacket() ([]byte, error) {
	var payload []byte
	for {
		// Read packet header
		data, err := mc.buf.readNext(4)
		if err != nil {
			errLog.Print(err)//在此處輸出錯誤
			mc.Close()
			return nil, driver.ErrBadConn
		}
        ·······
	}
}

在errLog.Print(err)下面加一行panic(err)，就能夠知道是哪調用的readPacket()，並在mc.buf.readNext(4)這一行下面添加errLog.Print("readPacket:", data, err)，觀察下輸出的數據; 下面是panic信息：

[mysql] 2016/12/29 15:08:16 packets.go:32: readPacket:[] unexpected EOF
[mysql] 2016/12/29 15:08:16 packets.go:34: unexpected EOF
panic: unexpected EOF

goroutine 16 [running]:
panic(0x877700, 0xc82000a180)
	/home/project/go/src/runtime/panic.go:481 +0x3e6
github.com/go-sql-driver/mysql.(*mysqlConn).readPacket(0xc820082870, 0x0, 0x0, 0x0, 0x0, 0x0)
	/home/project/webroot/test/src/github.com/go-sql-driver/mysql/packets.go:35 +0x384
github.com/go-sql-driver/mysql.(*mysqlStmt).readPrepareResultPacket(0xc820104e10, 0xc820104e10, 0x0, 0x0)
	/home/project/webroot/test/src/github.com/go-sql-driver/mysql/packets.go:757 +0x48
github.com/go-sql-driver/mysql.(*mysqlConn).Prepare(0xc820082870, 0xc820082990, 0x85, 0x0, 0x0, 0x0, 0x0)
	/home/project/webroot/test/src/github.com/go-sql-driver/mysql/connection.go:121 +0x21f
database/sql.(*DB).queryConn(0xc8200c22c0, 0xc82005ae70, 0xc82010cc70, 0xc820082990, 0x85, 0xc8201091c0, 0x4, 0x4, 0xc820082990, 0x0, ...)
	/home/project/go/src/database/sql/sql.go:1110 +0x31a
database/sql.(*DB).query(0xc8200c22c0, 0xc820082990, 0x85, 0xc8201091c0, 0x4, 0x4, 0x224b1b01, 0x4c1328, 0x0, 0x0)
	/home/project/go/src/database/sql/sql.go:1078 +0x126
database/sql.(*DB).Query(0xc8200c22c0, 0xc820082990, 0x85, 0xc8201091c0, 0x4, 0x4, 0x0, 0x0, 0x0)
	/home/project/go/src/database/sql/sql.go:1061 +0xa3
models.TestDbQuery(0xc820082990, 0x85, 0xc8201091c0, 0x4, 0x4, 0x0, 0x0, 0x0)
	/home/project/webroot/test/src/models/db_test.go:77 +0xb5
models.GetSomeTasks(0x0, 0x0, 0x0, 0x0, 0x0)
	/home/project/webroot/test/src/models/tasks.go:46 +0x2e1
logic.ScanTasks(0xc820100a60, 0xc8200649c0)
	/home/project/webroot/test/src/logic/group.go:23 +0x84
created by main.main
	/home/project/webroot/test/src/main.go:87 +0x3e5

按着上面顯示的方法，逐個查看也並未發現有什麼錯誤。

既然代碼這方面沒有什麼明顯錯誤，那就查看下mysql server端，查看設置的超時時間：

mysql> show variables like "%timeout%";
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 10       |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 50       |
| innodb_rollback_on_timeout | OFF      |
| interactive_timeout        | 600      |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 30       |
| net_write_timeout          | 60       |
| slave_net_timeout          | 3600     |
| wait_timeout               | 600      |
+----------------------------+----------+
10 rows in set (0.01 sec)

interactive_timeout和wait_timeout都是600，在短短几秒內不會斷開鏈接，百思不得其解啊，最後查看下my.cnf，發現interactive_timeout和wait_timeout這兩個的值是5，到此明瞭了，果真是鏈接的問題，以前顯示600是由於多天前作實驗設置爲600了，可是這個只是對當前session有效，實際程序中的時間仍是5sec。

注意：作完實驗後及時改回配置文件。