InnoDB与MyISAM
Mysql 在5.5之前默认使用 MyISAM 存储引擎，之后使用 InnoDB。
MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。
而 InnoDB与MyISAM 的最大不同有两点：一是 InnoDB支持事务；二是 InnoDB采用了行级锁。
在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。
乐观锁与悲观锁
乐观锁：总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。
version方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
核心SQL代码：
update table set x=x+1, version=version+1 where id=#{id} and version=#{version};
CAS操作方式：即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。
乐观锁一般乐观锁只用在高并发、多读少写的场景。
悲观锁： 总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁。共享锁、排它锁都是悲观锁。 一旦通过悲观锁锁定一个资源，那么其他需要操作该资源的使用方，只能等待直到锁被释放，好处在于可以减少并发，但是当并发量非常大的时候，由于锁消耗资源，并且可能锁定时间过长，容易导致系统性能下降，资源消耗严重。因此一般我们可以在并发量不是很大，并且出现并发情况导致的异常用户和系统都很难以接受的情况下，会选择悲观锁进行。
共享锁与排他锁
数据库的增删改操作默认都会加排他锁，而查询不会加任何锁。
共享锁（读锁）：对某一资源加共享锁，自身可以读该资源，其他人也可以读该资源（也可以再继续加共享锁，即 共享锁可多个共存），但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为：
select * from table lock in share mode
排他锁（写锁）：对某一资源加排他锁，自身可以进行增删改查，其他人无法进行任何操作。语法为：
select * from table for update –增删改自动加了排他锁
另外，对于获取共享锁后执行更新操作，可能会引起死锁。如事务A申请了行X的共享锁，事务B接着也申请了行X的共享锁，这时事务A要对行X进行更新操作，那么就需要等待行X上其他事务释放共享锁后获取排他锁，但事务B也要执行更新操作，这时便产生死锁（参考深入浅出MYSQL - InnoDB的行锁模式及加锁方法）：
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
所以如果需要执行更新操作，应该直接申请获取排他锁，而不是共享锁。
参考文章：https://blog.csdn.net/weixin_43152242/article/details/82501403