悲观锁通过加锁防止冲突，适合高并发写场景；乐观锁依赖版本控制，适合读多写少场景，二者根据业务权衡使用。
在MySQL中，乐观锁和悲观锁是两种不同的并发控制策略，用来解决多线程或多事务环境下对同一数据的读写冲突。它们不是MySQL内置的锁类型，而是设计层面的思想，通过不同的机制来实现。
悲观锁：假设冲突总会发生
悲观锁认为：只要不加锁，就可能发生数据冲突。因此，在操作数据前，先加锁，确保整个操作过程中数据不会被其他事务修改。
在MySQL中，通常通过SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE来实现悲观锁，这些语句只能在REPEATABLE READ或更高隔离级别下生效，并且需要开启事务。
使用场景举例：
- 用户下单扣减库存时，先查询库存，再更新。为防止超卖，可在查询时加锁：
START TRANSACTION; SELECT stock FROM products WHERE id = 1 FOR UPDATE; -- 检查库存是否足够 UPDATE products SET stock = stock - 1 WHERE id = 1; COMMIT;
此时其他事务无法同时对该行进行读写（直到当前事务提交），从而保证数据一致性。
乐观锁：假设冲突很少发生
乐观锁认为：大多数情况下不会发生冲突，所以不加锁。在更新时才检查数据是否被他人修改过。如果被改了，就放弃或重试。
实现方式通常是给表加一个版本号字段（version）或时间戳字段。每次更新时，检查版本是否匹配，同时更新版本号。
示例：
- 表结构包含 version 字段：
ALTER TABLE products ADD COLUMN version INT DEFAULT 0;
- 更新时判断版本：
UPDATE products SET stock = stock - 1, version = version + 1 WHERE id = 1 AND version = 2;
如果返回影响行数为0，说明版本不匹配，数据已被其他事务修改，当前操作需重试或报错。
两者对比与选择
悲观锁适合：
乐观锁适合：
- 读多写少的场景
- 冲突概率低，追求高并发性能
- 可以容忍失败后重试
注意：乐观锁的“检查-更新”必须是原子操作，不能拆成两个SQL，否则会失去意义。
基本上就这些。理解它们的关键是：悲观锁提前预防，牺牲效率保安全；乐观锁事后校验，提升并发但可能失败。根据业务场景权衡使用即可。
