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

gorm大版本更新之后，驱动的引入及实际的用法和老版本会有一些区别，特别是事务、锁的使用以及配置项的修改。 新版本gorm数据库链接方式以及包的名称和老版本相比均有改变，如下：

老版本：

而新版本：

老版本的配置项通过db.xx的形式修改：

而新版本均通过&gorm.Config{}字段进行修改：

forupdate的用法改变： 最开始依旧使用老版本的用法来使用，但是一直不成功，然后使用debug打印sql语句，发现生成的sql语句并没有for update相关操作，再去查找资料，发现老版本写法不生效，更换为新的写法。 老版本：

新版本：

在一个类似于转账的场景，为了保证转账的一致性，在相关的接口中使用了事务来保证转账成功，在最后测试同一个账户有人转出，有人转入时出现死锁； 根据网上查询以及一位大佬博文（http://t.csdn.cn/nAzEf）的思路下，在终端还原了死锁场景。 分别开启两个事务，按照顺序进行update操作：在执行第4步即事务2中的第二条操作时，出现死锁。

查询相关锁的表，能看到在发生死锁的上一步：

分别运行以下两个语句：

运行：

可以看到 可以看到，两个事务均获得了锁，进行了第3个操作时，事务1阻塞，等待事务2释放 锁；如果此时事务2不释放锁，反而执行第4个操作，则会造成事务2请求锁，但此时锁在事务1处，而事务1已经阻塞，无法释放锁，则事务2也会被阻塞，形成死锁。

解决办法则是： 调换4个语句的执行顺序； 如果按照1-4-3-2的顺序来进行则不会造成死锁。 因为在执行1后，事务1获得锁1，此时事务2执行4，事务2请求锁1，此时事务2阻塞； 事务1再执行3，获得锁2；此时事务1执行完毕，commit释放锁1和锁2，事务2获得锁1，语句4执行成功，再执行语句2成功，则不会发生死锁。

换到代码中则是对执行顺序进行排列，利用id为数字格式，可以比大小，则按照大小进行排列即可；