你有没有遇到过这样的情况？公司月底结账时，财务系统一查数据就卡住，点个提交按钮要等十几秒。其实问题很可能出在事务处理上。数据库每天要处理成千上万条事务，如果设计不合理，再好的硬件也扛不住。
合理控制事务大小
很多人习惯把一堆操作包在一个事务里，觉得这样“原子性”更强。但大事务会锁住更多资源，拖慢整体响应。比如一个订单流程，没必要从用户点击下单到发邮件全塞进同一个事务。可以把核心扣库存、生成订单放在事务内，发通知这类操作挪出去异步执行。
避免长事务占用资源
有个客户反馈系统老是超时，排查发现是某个报表查询用了事务且持续几分钟。长时间持有锁会导致其他写操作排队。对于只读查询，完全可以关闭自动事务或使用快照隔离级别。像MySQL可以用SET TRANSACTION READ ONLY来优化。
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
COMMIT;上面这段转账代码很常见，但如果中间加了日志记录、外部调用，事务时间就会拉长。建议把非关键动作移出事务块。
索引不是越多越好
事务中频繁更新的表如果建了太多索引，每次写入都要同步维护多个B+树，性能自然下降。曾见过一张订单明细表加了7个索引，导致插入速度暴跌。实际上根据查询条件保留最关键的3到4个就够了，比如(user_id, create_time)这种组合索引往往就能覆盖大部分场景。
善用批量处理
需要处理大量数据时，别一条条提交事务。比如每天凌晨同步用户积分，与其循环执行10万次单条UPDATE，不如按1000条一组提交。虽然总耗时可能差不多，但减少了事务开销和锁竞争。
INSERT INTO user_points (user_id, points) VALUES
(1, 10), (2, 15), (3, 8), (4, 20);
-- 提交一次即可选择合适的隔离级别
默认的可重复读（Repeatable Read）能防止幻读，但也带来更多间隙锁。如果业务允许一定程度的不一致，比如统计类接口，可以降为读已提交（Read Committed）。SQL Server和PostgreSQL都支持语句级指定隔离级别，灵活调整效果明显。
有一次帮电商项目调优，把商品浏览相关的查询从RR降到RC，并发能力直接提升了三倍。用户根本察觉不到细微的数据波动，但系统轻松多了。
监控事务等待链
定期查看数据库的锁等待情况，能提前发现问题。MySQL的information_schema.INNODB_TRX表可以看当前活跃事务，结合SHOW ENGINE INNODB STATUS能定位阻塞源头。某次发现两个微服务总互相死锁，最后通过统一加锁顺序解决了问题。