1. 数据库并发问题全景解读
当多个事务同时操作数据库时，会出现三类典型的并发问题：脏读（Dirty Read）、不可重复读（Non-repeatable Read）和幻读（Phantom Read）。这些问题就像多人同时编辑同一份文档时出现的冲突场景——有人看到未保存的草稿，有人发现之前查到的数据突然变化，还有人发现凭空多出了新记录。
以电商库存系统为例：事务A查询商品库存为100件，此时事务B修改库存为80件但尚未提交。如果事务A读取到未提交的80这个"脏数据"，就可能做出错误的库存判断。这就是典型的脏读场景。
2. 三大问题深度解析
2.1 脏读：读取未提交的"幽灵数据"
脏读发生在事务A读取了事务B修改但未提交的数据时。如果事务B最终回滚，事务A使用的就是根本不存在的"幽灵数据"。
sql复制-- 事务B（未提交）
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
-- 事务A读取到未提交的修改
SELECT balance FROM accounts WHERE user_id = 1; -- 看到减少后的余额
-- 事务B回滚
ROLLBACK;
关键特征：读取到其他事务未提交的中间状态数据，这些数据可能最终不会真实存在
2.2 不可重复读：同一查询结果前后不一
不可重复读指在同一事务内，连续两次执行相同查询却得到不同结果。这通常是因为其他已提交事务修改了数据。
sql复制-- 事务A第一次查询
SELECT quantity FROM products WHERE id = 101; -- 返回100
-- 事务B提交更新
UPDATE products SET quantity = 80 WHERE id = 101;
COMMIT;
-- 事务A第二次相同查询
SELECT quantity FROM products WHERE id = 101; -- 返回80
与脏读的区别：这里读取的是已提交的数据，但破坏了事务内的一致性预期
2.3 幻读：神秘出现的数据行
幻读特指在同一事务内，相同的条件查询突然返回了之前不存在的"幻影行"。这通常是因为其他事务插入了新记录。
sql复制-- 事务A第一次查询
SELECT * FROM orders WHERE user_id = 1; -- 返回3条记录
-- 事务B插入新订单并提交
INSERT INTO orders(user_id, amount) VALUES (1, 200);
COMMIT;
-- 事务A第二次相同查询
SELECT * FROM orders WHERE user_id = 1; -- 返回4条记录
特殊之处：影响的是结果集的行数，而非特定行的内容
3. 隔离级别的防御机制
3.1 SQL标准四级隔离对照表
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| READ UNCOMMITTED | 可能 | 可能 | 可能 |
| READ COMMITTED | 避免 | 可能 | 可能 |
| REPEATABLE READ | 避免 | 避免 | 可能 |
| SERIALIZABLE | 避免 | 避免 | 避免 |
3.2 各数据库实现差异
-
MySQL InnoDB：
- 默认REPEATABLE READ级别下通过MVCC+间隙锁可避免幻读
- 实际表现接近SERIALIZABLE但并发性能更好
-
PostgreSQL：
- REPEATABLE READ不会阻止幻读
- 需升级到SERIALIZABLE才能完全避免
-
Oracle：
- 默认READ COMMITTED
- 提供SNAPSHOT ISOLATION作为扩展
4. 实战解决方案
4.1 锁机制应用实例
sql复制-- 悲观锁方案（SELECT FOR UPDATE）
BEGIN;
SELECT * FROM products WHERE id = 101 FOR UPDATE; -- 获取排他锁
UPDATE products SET stock = stock - 1 WHERE id = 101;
COMMIT;
-- 乐观锁方案
UPDATE products
SET stock = stock - 1, version = version + 1
WHERE id = 101 AND version = 5; -- 检查版本号
4.2 多版本并发控制(MVCC)
MVCC通过保存数据的历史版本实现：
- 每个事务看到的是特定时间点的数据快照
- 写操作创建新版本，读操作访问旧版本
- 通过事务ID和版本链实现无锁读取
4.3 应用层防御策略
- 短事务原则：减少事务持续时间
- 适当重试机制：对乐观锁冲突自动重试
- 业务逻辑校验：如库存检查需在事务最后再次确认
5. 生产环境诊断与调优
5.1 问题诊断工具
sql复制-- MySQL查看当前会话隔离级别
SELECT @@transaction_isolation;
-- 查看锁等待情况
SHOW ENGINE INNODB STATUS;
5.2 性能优化平衡点
- 银行交易系统：通常需要SERIALIZABLE
- 社交网络Feed流：可接受READ COMMITTED
- 电商库存系统：推荐REPEATABLE READ+乐观锁
5.3 经典踩坑案例
- 财务系统误用READ UNCOMMITTED导致金额计算错误
- 报表系统在REPEATABLE READ下读取到历史快照
- 批量导入未使用事务导致部分成功部分失败
6. 新型数据库的并发控制
分布式数据库如TiDB采用Percolator模型：
- 全局时间戳分配
- 两阶段提交+乐观并发控制
- 通过Region拆分减少冲突
我在处理一个高并发票务系统时，最终采用的方案是REPEATABLE READ隔离级别配合Redis分布式锁做第一层拦截，数据库层面通过SELECT...FOR UPDATE确保强一致性，同时设置锁超时时间防止死锁。这套方案经受了秒杀场景的实际考验，在保证数据一致性的同时维持了3000+ TPS的处理能力。