MySQL中的乐不雅观锁是一种并发掌握策略，它基于这样一种假设：在大多数情形下，多个事务同时修正同一份数据的可能性很小，即数据并发冲突的概率较低。乐不雅观锁并不会在事务开始时就对数据进行实际锁定，而是许可事务自由地进行读取和修正操作。以是乐不雅观锁虽然叫锁，但实际并没有锁的存在，是逻辑掌握修正操作。乐不雅观锁实在便是 CAS，compare and swap，我们也叫做无锁办理并发效果。
实现办法一：
数据库表中添加一个额外的列作为版本号（version），当一个事务想要更新某行数据时，首先读取该行数据确当前版本号，在事务提交更新时，会再次检讨该行数据的版本号是否与最初读取时相同。如果相同，则解释在这段韶光内没有其他事务修正过该数据，当前事务可以安全地进行更新，并将版本号加一。如果创造版本号已经改变，则认为数据已被其他事务修正，当前事务的更新操作将被放弃，可以根据业务需求选择回滚事务或重新考试测验。
update table_name set xxx = ???, version = current_version + 1 where version = current_version
Q：假设当前有1000个并发同时要求，那么，对应到这条 SQL 语句的实行，会是什么效果？
A：999个失落败，1个成功
实现办法二：
数据表中利用两个字段来实现乐不雅观锁: used, total; used 的代表已经已卖库存，total 代表总库存；我假设每次减一个库存，那么，乐不雅观锁 SQL 变成这样：
update table_name set xxx = ???, used = used + 1 where used + 1 <= total
Q：假设当前有1000个并发同时要求，那么，对应到这条 SQL 语句的实行，会是什么效果？
A：1000个成功
以上，第一种实现办法适宜读多写少的场景，不适宜高并发场景；第二种实现办法适宜并发不高，比如说只有几十、几百 QPS，由于还是有大量的要求到了 MySQL，并且是写操作，无法利用读写分离优化，会增加系统的繁芜性和降落吞吐量。
末了，推举一个自己搭建的通用管理后台脚手架，记得Star哦巨比特 - 通用管理后台: 开箱即用的后台管理系统，已做事公司内部多个项目，大略易用。
