悲观锁在操作前加锁，通过select for UPDATE实现，适合写多高冲突场景；乐观锁在提交时检查版本号，适合读多写少场景，二者根据业务需求权衡选择。
乐观锁和悲观锁是数据库中处理并发控制的两种策略，它们在实现方式、适用场景和性能表现上有明显区别。mysql本身没有直接提供“乐观锁”或“悲观锁”的语法关键字，但可以通过具体机制来体现这两种思想。
悲观锁：假设冲突总会发生
悲观锁认为在操作数据的过程中，很可能会有其他事务修改同一数据，因此在访问数据时会先加锁，防止其他事务修改。
在MySQL中，通常通过 SELECT … FOR UPDATE 或 SELECT … LOCK IN SHARE MODE 来实现悲观锁，这些语句只能在事务中使用（如InnoDB引擎）。
举例：
开启事务后执行：
SELECT * FROM users WHERE id = 1 FOR UPDATE;
这条语句会锁定该行记录，直到当前事务结束，其他事务无法修改或加排他锁，从而保证数据安全。
适合场景：
- 写操作频繁，冲突概率高
- 数据一致性要求非常严格
- 如金融交易、库存扣减等
乐观锁：假设冲突很少发生
乐观锁认为大多数情况下不会发生并发冲突，因此在读取时不加锁。只有在更新时才会检查在此期间是否有其他事务修改过数据。
常见的实现方式是在表中增加一个版本号字段（version）或时间戳（timestamp）。每次更新时对比版本号，若不一致则说明数据已被修改，更新失败。
举例：
更新用户余额时：
UPDATE users SET balance = 90, version = version + 1 WHERE id = 1 AND version = 1;
如果返回影响行数为0，说明版本不匹配，其他事务已修改，当前操作需重试或提示失败。
适合场景：
- 读多写少
- 并发冲突较少
- 如文章点赞、浏览量统计等
核心区别总结
加锁时机不同： 悲观锁在操作前就加锁，乐观锁在提交时才检查冲突。
性能表现： 悲观锁开销大，可能造成阻塞；乐观锁开销小，但在冲突频繁时会导致大量重试。
一致性保障： 悲观锁能更强地保证数据一致性，乐观锁依赖应用层逻辑处理失败情况。
基本上就这些，选择哪种方式要看业务对并发、性能和一致性的权衡。