请教一下 MySQL 的乐观锁改造问题

[jin2ml]

今天接到一个技术任务，要改造一下当前的数据库，实现一下乐观锁。项目用了 mybatis-plus ，所以我准备用数据库表添加 version 字段的方式进行操作，配合框架的插件配置，可以实现 updateById(),update(entity,wrapper)这两个方法的更新乐观锁，但是项目中还有其他的更新方式是自定义的 mapper ，对于这部分的内容，应该用什么方式比较好呢？目前我想到的就是在 sql 解析的时候看看能不能有切入点。 望各位大佬不吝赐教！

[ferock]

自定义 mapper 那就手写 sql 呀

[dqzcwxb]

就别折腾数据库的锁了,跨库直接 gg
上分布式锁不好吗,简单又好用

[jin2ml]

@ferock 你说的没错，手写肯定可以满足需求，但是我还是想知道是否可以通过拦截器这类的方式进行统一修改，这样工作量也会小些。

[jin2ml]

@dqzcwxb 目前我们都是单库，而且我们项目实现的 Redis 锁我看了源码了也不支持分布式锁，只能单机适用，解锁的操作都不是原子性的，锁的客户端 id 还是 UUID 实现的无法做到分布式唯一。。。今天我去公司看看能不能睡服领导^_^!

[ferock]

@jin2ml #4

睡服…领导…

[chengyiqun]

@jin2ml #4 睡服.... 我大写的服

[themostlazyman]

https://baomidou.com/pages/0d93c0/#optimisticlockerinnerinterceptor

[themostlazyman]

@themostlazyman 没读清题，建议把手写 sql ，改成 updateById(),update(entity,wrapper)；

[haoooooo]

睡服 屌爆!

[nothingistrue]

乐观锁原本就是个软规范，你用硬规范是很难搞定的。如果非要搞，不要在 updateById(),update(entity,wrapper) 这些方法上搞，而是从 实体 Entity 上搞，乐观锁的主体是实体，不是 CRUD 方法。

以上仅限于新项目可搞，老项目就算了，强搞建议直接提桶跑路。因为乐观锁的主体是实体，这意味仅借助而非强依赖于实体的操作——比如自定义 mapper ，是搞不了乐观锁的。所以要搞必须额外加规范：一切以实体为主。这样老项目根本搞不了，改造难度太大了。

此外，乐观锁属于程序的范畴，不是 SQL 的范畴，你发错节点了。

[cheng6563]

老系统一堆意义不明的 UPDATE 就别乐观锁了

[wqhui]

https://baomidou.com/pages/2976a3/#mybatisplusinterceptor ，mybatis-plus 的乐观锁拦截器是通过这个去做的，可以自己写一个拦截器放进去，或者实现 org.apache.ibatis.plugin.Interceptor

[zmal]

代码层面可能无法强制规范，是否可以建 version + id 的索引，强制 update 语句必须使用该索引，未用到该索引的语句在 SQL 层面直接报错。

[jin2ml]

@nothingistrue 感谢大佬的认真回复！首先节点问题确实不对，我发完主题想了一下就感觉不太合适，放 Java 可能更合适一些。准备先睡服一下，睡服不了我就把自定义的 sql 拉出来让领导定是不是要一个一个搞。对于自定义的 mapper 拦截器的话感觉很难普遍适用