上一篇
数据库事务怎么写
库事务编写需遵循ACID原则，用START TRANSACTION开启，执行多条SQL后，依情况COMMIT提交
库事务是确保数据完整性和一致性的关键机制，它将一组SQL操作绑定为一个逻辑单元，要么全部成功执行，要么完全回滚,以下是关于如何编写数据库事务的详细说明：
理解事务的核心概念与ACID特性
- 定义：事务（Transaction）是由多个数据库操作组成的最小工作单元，这些操作要么全部完成，要么全部撤销，银行转账时从A账户扣款并同步向B账户加款的过程就是一个典型事务，若中间任何步骤失败（如网络中断或余额不足）,整个流程必须回滚以保持数据原始状态。
- 四大特性（ACID）
- A原子性（Atomicity）：保证所有操作不可分割，通过undo log记录反向操作实现失败时的完整回滚，当执行到第五步发现B账户异常时,系统会自动撤销前几步对A账户的修改；
- C一致性（Consistency）：维护数据库状态合法，如转账前后总金额不变,触发器校验约束条件等；
- I隔离性（Isolation）：控制并发访问冲突，采用MVCC多版本并发控制技术为不同事务分配独立快照，避免脏读、不可重复读等问题；
- D持久性（Durability）：通过redo log重做日志确保提交后的修改永久生效,即使系统崩溃也不会丢失。
事务的具体实现步骤
开启事务
使用显式命令启动一个事务块：START TRANSACTION;或简写为BEGIN;，此时后续的所有SQL语句都将纳入该事务中，直到遇到提交或回滚指令，例如在MySQL中默认自动提交模式下，需先执行SET @@autocommit=0;关闭自动提交功能才能手动管理事务边界。
执行业务逻辑
将相关的DML语句按顺序排列组合,以转账为例：
UPDATE accounts SET balance = balance 100 WHERE id = 1; -从A账户扣款 UPDATE accounts SET balance = balance + 100 WHERE id = 2; -向B账户汇款
注意：这里两条更新必须连续执行且互依赖存,中间不能穿插其他会话的操作。
提交/回滚决策
- 正常流程：若全部操作成功则用
COMMIT;永久保存更改，一旦提交,其他会话即可看到新数据； - 异常处理：发生错误时调用
ROLLBACK;撤销当前事务内的所有修改,这常用于捕获程序异常或业务规则校验失败的场景； - 保存点优化：复杂事务可通过
SAVEPOINT sp_name;设置中途标记点,实现部分回溯而非整体作废。
隔离级别的选择策略
根据业务场景权衡性能与数据安全性的需求，选择合适的隔离级别至关重要：
| 级别 | 脏读 | 不可重复读 | 幻读 | 适用场景 |
|———————|——|————|————|——————————|
| Read Uncommitted | ️ | ️ | ️ | 对数据实时性要求极高的监控类应用 |
| Read Committed | | ️ | ️ | 大多数标准CRUD操作 |
| Repeatable Read | | | ️ | MySQL默认级别，适合财务系统 |
| Serializable | | | | 强一致性要求的高精度计算 |
典型配置示例：SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
常见问题及解决方案
| 现象 | 描述 | 根本原因 | 解决办法 |
|---|---|---|---|
| 脏读 | 读到其他事务未提交的数据快照 | 低隔离级别允许脏读 | 提升至Read Committed以上 |
| 不可重复读 | 同一字段多次查询结果不一致 | 版本混杂导致视图变化 | 启用Repeatable Read |
| 幻读 | 范围查询返回记录数突然增加/减少 | 新建条目影响聚合判断 | 升级到Serializable |
实践案例对比分析
假设两个用户同时进行资金划转：
- 无事务控制：可能出现A用户提款成功但存款未到账的情况,导致总资产莫名增加；
- 带事务控制：通过锁机制或MVCC保证两个操作原子化执行,即使并发也能维持李会计总账平衡。
FAQs：
-
问：为什么设置了正确的隔离级别仍然出现数据不一致？
答：可能是由于长事务持有锁的时间过长导致阻塞链形成，建议缩短事务周期，及时提交中间结果释放资源，此外某些存储引擎的特性也可能影响效果（如MyISAM不支持事务）。 -
问：如何在高并发场景下优化事务性能？
答：可采用分库分表减少单点竞争；合理设计索引加速查找速度；尽量将大事务拆分成小批次处理；使用乐观锁替代悲观锁降低等待时间，同时监控Innodb行锁冲突情况，调整`innodb_lock_wait
