Remember a gorm transaction and debug to solve mysql deadlock

前言

之前使用mysql和postgresql是通过sqlc包来使用,这一次使用gorm,还是遇到了很多问题,在此记录以下.

版本问题

gormAfter a major version update,The introduction and actual usage of the driver will be slightly different from the old version,Especially business、Use of locks and modification of configuration items.
新版本gormDatabase linking and package names have changed compared to the old version,如下：

老版本：

import (
	"github.com/jinzhu/gorm"
	_ "github.com/jinzhu/gorm/dialects/mysql"
)

db, err := gorm.Open("mysql", "root:[email protected](127.0.0.1:3306)/db01?&parseTime=True&loc=Local")

而新版本：

import (
	"gorm.io/driver/mysql"
	"gorm.io/gorm"
	"gorm.io/gorm/schema"
)

db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
    })

The configuration items of the old version are passeddb.xx的形式修改：

	db.LogMode(true)
	db.DB().SetMaxIdleConns(10)
	db.DB().SetMaxOpenConns(100)
	db.SingularTable(true)

The new version passed&gorm.Config{}字段进行修改：

db, err = gorm.Open(mysql.Open(dbLink), &gorm.Config{
    
		SkipDefaultTransaction: true,  //开启事务
		NamingStrategy: schema.NamingStrategy{
    
			SingularTable: true,
		},

forupdateusage changed：
At first, it was still used in the old version,但是一直不成功,然后使用debug打印sql语句,发现生成的sql语句并没有for update相关操作,Go to find information,Found that the old version of the writing does not take effect,Replace with new spelling.
老版本：

 result := tx.Debug().Set("gorm:query_option", "FOR UPDATE").First(&user1, arg.FromUserID)

新版本：

result = tx.Debug().Clauses(clause.Locking{
    Strength: "UPDATE"}).First(&user2, arg.ToUserID)

Database deadlock troubleshooting：

In a scenario similar to a transfer,In order to ensure the consistency of transfers,Transactions are used in related interfaces to ensure successful transfers,In the last test someone transferred out of the same account,A deadlock occurs when someone transfers in;
According to online queries and a blog post by a big guy（http://t.csdn.cn/nAzEf）的思路下,Restored deadlock scenarios in the terminal.
分别开启两个事务,按照顺序进行update操作：在执行第4step is business2when the second operation in ,出现死锁.

事务1：
1 update user set collection_coins = collection_coins - 10 where id = 1537973755;
3 update user set collection_coins = collection_coins + 10 where id = 1338725819;   等待获取锁

事务2：

2 update user set collection_coins = collection_coins - 10 where id = 1338725819;
4 update user set collection_coins = collection_coins + 10 where id = 1537973755;  

Query the table for related locks,Can see the previous step where the deadlock occurred：

Run the following two statements separately：

select * from information_schema.innodb_locks;
select * from information_schema.innodb_lock_waits;

运行：

SELECT * FROM information_schema.innodb_trx;

可以看到

可以看到,Both transactions acquired the lock,进行了第3个操作时,事务1阻塞,等待事务2释放
锁;如果此时事务2不释放锁,Instead, execute No4个操作,will result in a transaction2请求锁,But this time the lock is in the transaction1处,而事务1已经阻塞,无法释放锁,则事务2也会被阻塞,形成死锁.

The solution is：
调换4order of execution of the statements;
如果按照1-4-3-2order will not cause deadlock.
因为在执行1后,事务1获得锁1,此时事务2执行4,事务2请求锁1,此时事务2阻塞;
事务1再执行3,获得锁2;此时事务1执行完毕,commit释放锁1和锁2,事务2获得锁1,语句4执行成功,再执行语句2成功,则不会发生死锁.

Switching to the code is to arrange the order of execution,利用id为数字格式,可以比大小,You can arrange them by size;