1. 假定某商品库存为10,数据库使用mysql的默认隔离级别，请问扣减一个库存同时，有一个查询，查询到的数据库存是多少?
🧠 分析过程
MySQL 默认隔离级别：REPEATABLE READ
MySQL InnoDB 的默认隔离级别是 可重复读（REPEATABLE READ） ，其核心特征：
- 通过 MVCC（多版本并发控制） 实现；
- 一个事务中多次读取同一行数据，结果一致（除非自己修改）；
- 在未提交事务中修改的数据，其他事务看不到；
- 避免了脏读。
🧾 举例分析
| 时间顺序 | 操作 | 说明 |
|---|
| t1 | 事务A开始 | 扣减库存事务开始 |
| t2 | 事务A执行 UPDATE product SET stock = stock - 1 WHERE id = 1; | 将库存改为 9，但未提交 |
| t3 | 事务B执行 SELECT stock FROM product WHERE id = 1; | 查询库存 |
| t4 | 事务A提交 | 扣减完成 |
🔍 t3 时刻：事务B 查询到的结果
因为 MySQL 在 REPEATABLE READ 隔离级别下，
事务B 看不到事务A未提交的修改（MVCC 保证），
所以：
✅ 事务B 查询到的库存 = 10
即使事务A已经执行了 UPDATE，但未提交，其他事务看到的仍是旧版本。
✅ 总结结论
| 项目 | 说明 |
|---|
| 数据库隔离级别 | REPEATABLE READ（默认） |
| 库存初始值 | 10 |
| 事务A操作 | UPDATE stock = 9（未提交） |
| 事务B操作 | SELECT stock |
| 查询结果 | 10 |
| 原因 | MVCC 保证读到的是已提交版本，避免脏读 |
💡 补充：如果换隔离级别会怎样
| 隔离级别 | 查询结果 | 原因 |
|---|
| READ UNCOMMITTED | 9 | 能读到未提交数据（脏读） |
| READ COMMITTED | 10 | 只能读到已提交数据 |
| REPEATABLE READ（默认） | 10 | 使用快照读，读到的是事务开始时的版本 |
| SERIALIZABLE | 10 | 加锁读，阻塞直到事务A提交或回滚 |
2.数据库s锁与x锁
🧩 一、S锁与X锁的基本定义
| 锁类型 | 全称 | 英文名称 | 作用 |
|---|
| S锁 | 共享锁 | Shared Lock | 允许多个事务同时读取同一行，但不允许修改 |
| X锁 | 排他锁 | Exclusive Lock | 只允许一个事务对该行进行读写，其他事务不能再加任何锁 |
🧠 二、加锁后的行为差异
| 操作类型 | 需要的锁类型 | 是否允许并发 |
|---|
SELECT ... LOCK IN SHARE MODE | S锁 | ✅ 允许其他事务也加S锁（共享读） ❌ 不允许X锁（写） |
SELECT ... FOR UPDATE | X锁 | ❌ 其他事务不能加任何锁（读写都阻塞） |
UPDATE / DELETE / INSERT | X锁 | ❌ 独占该行 |
普通 SELECT（无锁读） | 不加锁（MVCC快照读） | ✅ 完全并发，读不阻塞写 |
🔐 三、S锁与X锁的兼容性矩阵
| 当前锁类型 | 申请锁类型 | 是否兼容 |
|---|
| S锁 | S锁 | ✅（可以同时读取） |
| S锁 | X锁 | ❌（阻塞） |
| X锁 | S锁 | ❌（阻塞） |
| X锁 | X锁 | ❌（阻塞） |
👉 结论：
📊 五、总结对比表
| 项目 | S锁（共享锁） | X锁（排他锁） |
|---|
| 允许读 | ✅ | ✅（自己可以） |
| 允许写 | ❌ | ✅（自己可以） |
| 可共存 | ✅ 多个S锁可共存 | ❌ 独占 |
| 与MVCC关系 | 显式加锁读 | 显式写操作 |
| 常见SQL | SELECT ... LOCK IN SHARE MODE | UPDATE、DELETE、SELECT ... FOR UPDATE |
💡 六、实际应用场景
| 场景 | 推荐锁类型 | 原因 |
|---|
| 需要读取后再判断是否更新 | SELECT ... FOR UPDATE | 确保数据不会被其他事务修改（加X锁） |
| 仅需读取但希望防止被删除或修改 | SELECT ... LOCK IN SHARE MODE | 加S锁防止数据被改动 |
| 只想查（读一致性） | 普通 SELECT | 使用MVCC，性能最佳 |
