MySQL中Update语句是悲观锁？还是乐观锁？

首先需要对乐观锁和悲观锁有所了解，只有了解了后才可能知道使用的是哪种锁。

悲观锁

当要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。

这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（又名“悲观锁”）。

之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。

但是在效率方面会让数据库产生额外的开销，还有增加产生死锁的机会；另外，还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

乐观锁

乐观锁是相对悲观锁而言的，乐观锁只有在数据进行提交更新的时候，才会对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

乐观并发控制相信事务之间的数据竞争的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

乐观锁和悲观锁如何选择？

在选择上主要看下两者的区别以及适用场景就可以了。

• 乐观锁：效率高。适用于读多写少的场景。不过一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。 
• 悲观锁：依赖数据库锁，效率低。更新失败的概率比较低。适用于写多读少的场景，且并发写入的概率较高的场景。

既然知道上边的情况了，那接下来分析一下Update是使用的悲观锁还是乐观锁？

在 MySQL 中的 Update 语句通常不会自动使用悲观锁或乐观锁。默认情况下，MySQL会根据隔离级别和并发控制策略来处理 Update 操作的并发访问。

如果使用了悲观锁，通常需要在查询时显式地使用 for update 子句，这会将选定的行进行加锁，防止其他事务对其进行修改，直到当前事务结束。

乐观锁一般不是通过 Update 语句实现的，而是通过在应用层面实现。常见的做法是在表中增加一个版本号或时间戳字段，每次更新时比较该字段的值，如果值未发生变化，则认为更新成功，否则需要重新尝试。

因此，MySQL中的 Update 语句在默认情况下不会使用悲观锁或乐观锁，而是根据隔离级别和并发控制策略来处理并发更新操作。