DB2作为企业级关系型数据库，其缺省的事务及并发锁机制是保障数据一致性和多用户并发访问稳定的核心设计，下面我们详细拆解这两部分的内容。
DB2缺省事务机制
DB2缺省情况下，事务遵循ACID四大特性，即原子性、一致性、隔离性、持久性，默认的事务行为是自动提交模式，也就是每条单独的SQL语句执行完成后会自动提交，不需要手动执行COMMIT命令。
事务的核心组成
缺省事务的生命周期包含以下几个关键环节：
- 事务开始：执行第一条SQL语句时自动启动事务，或者手动执行BEGIN TRANSACTION启动
- 事务执行：期间的所有增删改查操作都会被记录到事务日志中
- 事务提交：缺省自动提交时，语句执行成功就提交，持久化所有修改；手动模式下需要执行COMMIT命令
- 事务回滚：如果语句执行失败，或者手动执行ROLLBACK，会撤销事务内的所有未提交修改
缺省事务相关配置
可以通过以下命令查看当前DB2实例的缺省事务配置：
-- 查看当前事务自动提交状态 VALUES CURRENT AUTOCOMMIT; -- 查看缺省隔离级别 VALUES CURRENT ISOLATION;
DB2缺省并发锁机制
并发场景下多个事务同时操作同一份数据时，DB2缺省会启动锁机制来避免脏读、不可重复读、幻读等问题，同时尽可能提升并发性能。
缺省锁类型
DB2缺省会根据操作类型自动申请不同的锁：
| 锁类型 | 适用场景 | 缺省行为 |
|---|---|---|
| 共享锁（S锁） | 读操作（SELECT） | 多个事务可以同时持有同一对象的共享锁，互不阻塞 |
| 排他锁（X锁） | 写操作（INSERT/UPDATE/DELETE） | 排他锁会阻塞其他所有共享锁和排他锁，直到当前事务提交或回滚 |
| 意向锁 | 表级操作前的标记 | 缺省自动申请，用于快速判断表内是否有行级锁，提升锁冲突检测效率 |
缺省隔离级别
DB2缺省的隔离级别是CS（游标稳定性，Cursor Stability），这个级别会平衡一致性和并发性：
- 事务读取一行数据时，会持有该行的共享锁，直到游标离开该行或者事务结束
- 事务修改一行数据时，会持有该行的排他锁，直到事务提交或回滚
- 可以避免脏读，但是可能出现不可重复读和幻读
缺省锁超时与死锁处理
DB2缺省会设置锁超时时间，当某个事务等待锁的时间超过阈值，会自动回滚当前语句并抛出错误，避免无限等待。同时缺省开启死锁检测机制，定期扫描事务等待链，发现死锁时会选择回滚代价较小的事务，解除死锁状态。
以下是一个模拟缺省锁冲突的简单示例，两个事务同时操作同一行数据：
-- 事务1：缺省自动提交关闭，手动控制事务 UPDATE employee SET salary = salary + 1000 WHERE id = 1001; -- 事务2：同时执行同一条更新语句，此时会等待事务1的排他锁释放 UPDATE employee SET salary = salary + 1000 WHERE id = 1001;
缺省机制的注意事项
虽然DB2的缺省事务和锁机制能满足大部分常规场景，但在高并发或者特殊业务场景下，可能需要手动调整：比如需要更高的一致性可以切换到RR（可重复读）隔离级别，需要更高并发可以切换到UR（未提交读）隔离级别，也可以手动控制事务的提交和回滚，避免长事务持有锁时间过长影响其他操作。