案例分析
更新账户金额
直接更新
乐观锁方案
无锁方案
排队操作
常见问题
如果数据中存在 update_time 字段受影响的行数是多少？
如果执行 update 更新但受影响的行数为 0 会加行锁吗？
参考资料
本文将通过一个 用户账户金额更新的案例 分析几种数据更新的操作的优劣。希望对大家有帮助 🐶。
数据库版本 : mysql 5.7.23
创建数据库的DDL：
CREATE TABLE `hw_account` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(20) DEFAULT NULL,
`balance` int(11) DEFAULT NULL,
`status` varchar(20) DEFAULT NULL,
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
更新账户金额方案 1 查询后更新
# 数据查询
select * from hw_account where id = 1;
# 数据更新
update hw_account set balance = 5 where id = 1;
存在的问题，就是分两次操作，如果并发执行的时候，可能造成更新丢失的问题.
利用版本号操作，即对数据库增加乐观锁的方式进行。
# 数据查询
select * from hw_account where id = 1;
# 数据更新
update hw_account set balance = 5 , version = version + 1
where id = 1 and version = n;
# 判断是否成功
if row < 1 {
回滚
}
存在的问题，如果该条数据并发操作的时候，会导致其他的请求失败。如果这个请求的前置链路比较长的话， 回滚成本比较高。
不用查询，采用数据库的计算，也不需要版本号的操作，直接通过域值进行有效性判断。具体的 SQL 如下：
# 数据更新
update hw_account set balance = balance + @change_num , version = version + 1
where id = 1 and version = n;
# 判断是否成功
if row < 1 {
回滚
}
这种方案修改比较简单， 但是依赖于数据计算，感觉不是特别友好。
通过 redis 或者 zk 的分布式锁，进行数据请求进行排队。然后在进行数据更新。
# 伪代码
if (获取分布式锁) {
update hw_account set balance = @balance where id = 1;
} else {
# 进入等待，或者进行自旋获取锁
}
常见问题update_time 的字段定义如下，如果数据为id = 1, status = 1 如果执行更新数据的 sql 为
update hw_account set `status` = 1 where id = 1;
返回的受影响的行数为 0；
会的， 执行更新的语句都会加行锁（前提，事务内）
mysql.com
到此这篇关于MySQL几种更新操作的案例分析的文章就介绍到这了,更多相关MySQL 更新操作内容请搜索软件开发网以前的文章或继续浏览下面的相关文章希望大家以后多多支持软件开发网！