悲观锁假设冲突必然发生，通过SELECT...FOR UPDATE加锁，适用于高并发写场景；乐观锁假设冲突少，利用版本号检查更新，适合读多写少场景，二者分别在数据库层和应用层实现并发控制。
乐观锁和悲观锁是数据库中用来处理并发控制的两种策略，在 MySQL 中实现方式和适用场景有明显区别。
悲观锁：假设冲突一定会发生
悲观锁认为在操作数据的过程中，很可能会有其他事务来修改同一数据，因此在读取数据时就加锁，防止其他事务访问。
在 MySQL 中，通常通过 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 来实现。
例如：
执行 SELECT * FROM users WHERE id = 1 FOR UPDATE; 会锁定该行，直到当前事务结束，其他事务无法修改或加锁该行。
特点：
- 适用于写操作频繁、并发冲突概率高的场景
- 能有效避免脏写和丢失更新
- 但可能造成锁等待、死锁，降低并发性能
乐观锁：假设冲突很少发生
乐观锁不加锁，而是在更新时检查数据是否被其他事务修改过。通常通过版本号（version）或时间戳字段实现。
例如：
表中有一个 version 字段，读取时记录 version 值，更新时判断 version 是否变化：
UPDATE users SET name = 'Tom', version = version + 1 WHERE id = 1 AND version = 3;
如果影响行数为 0，说明 version 已被修改，更新失败，需要重试或提示用户。
特点：
- 适用于读多写少、并发冲突较少的场景
- 不阻塞其他事务，提高了并发吞吐量
- 需要应用层配合处理更新失败的情况
核心区别总结
悲观锁由数据库层面直接支持，通过行锁机制保证数据安全；乐观锁依赖应用逻辑，在更新时做一致性校验。
选择哪种方式，取决于业务场景对并发性能和数据一致性的权衡。
基本上就这些，不复杂但容易忽略实际使用中的重试机制和锁范围问题。