SQL数据一致性靠事务及ACID原则保障，需合理界定事务边界、匹配隔离级别、应用层协同校验与异常处理。
SQL数据一致性主要靠事务（Transaction）来保证，核心是遵循ACID原则——原子性、一致性、隔离性、持久性。不是靠单条语句写得“正确”，而是靠事务边界定义+恰当的隔离级别+应用层配合共同实现。
事务必须有明确的边界
很多一致性问题源于事务范围过小或过大。BEGIN/COMMIT不能只包一条UPDATE，也不能把整个业务流程硬塞进一个事务。
- 典型错误：用户下单时，扣库存和生成订单用两个独立事务——中间若失败，就会出现“库存已扣但订单没建”或“订单已建但库存没扣”的不一致
- 正确做法：将“查库存→扣库存→写订单→写订单明细”全部放在同一事务内，任一环节失败则整体回滚
- 注意：长事务会加剧锁冲突和主从延迟，涉及多表更新时优先考虑分库分表下的本地事务能力，必要时引入Saga等分布式事务模式
隔离级别要匹配业务真实需求
不是越高越好。READ COMMITTED能解决脏读，多数OLTP场景已足够；SERIALIZABLE虽强，但并发性能断崖式下降，还可能引发大量死锁。
- 电商秒杀需防超卖：用SELECT ... FOR UPDATE + REPEATABLE READ或更高隔离级，确保同一商品不会被两个事务同时扣减
- 报表统计类查询：可设为READ UNCOMMITTED或加NOLOCK（SQL Server），允许脏读换响应速度，因数据本就非强实时
- 关键金融转账：至少REPEATABLE READ，并在应用层校验余额是否充足，避免幻读导致重复扣款
一致性不只是数据库的事
数据库只保证自身约束（如外键、CHECK、唯一索引）生效，但业务规则（如“用户等级≥3才能发帖”）需应用层与数据库协同控制。
- 把校验逻辑下推到数据库：用BEFORE INSERT触发器或存储过程封装规则，比纯应用层判断更可靠
- 避免“先查后改”陷阱：比如“余额>100才允许提现”，不能SELECT余额→应用判断→UPDATE扣减，而应直接UPDATE ... WHERE balance >= 100，用影响行数判断是否成功
- 对账机制不可少：定时比对核心表（如账户余额表 vs 交易流水表）的汇总值，发现不一致立即告警并人工介入
异常必须显式处理，不能依赖自动回滚
数据库只在崩溃或显式ROLLBACK时回滚，程序抛异常但没捕获、没回滚，事务会一直挂着，造成连接泄漏和数据悬挂。
- 所有事务代码块必须配try-catch，catch中明确调用ROLLBACK，或使用支持自动回滚的框架（如Spring @Transactional rollbackFor）
- 设置合理的事务超时（如30秒），防止长阻塞拖垮整个连接池
- 日志里记录事务开始、关键操作点、结束状态（COMMIT/ROLLBACK），便于出问题时快速定位哪一步出错
不复杂但容易忽略。事务设计不是堆技术参数，而是理解业务动作的天然边界，再用数据库机制去对齐它。
