MySQL事务粒度控制需按业务语义合理划分边界，一个事务应完整表达不可分割的业务动作，避免过大导致锁争用或过小失去原子性，同时结合隔离级别、长事务防范与监控手段优化一致性与性能。
MySQL 中事务粒度控制，本质是平衡数据一致性、并发性能与系统复杂度。粒度过大（如整个业务流程包在一个事务里）容易导致锁等待、死锁和超时；粒度过小（如每个 SQL 都开事务）则失去事务保护意义，还增加引擎开销。关键不是“最小化”或“最大化”，而是按业务语义合理划分边界。
按业务用例确定事务边界
一个事务应完整表达一个不可分割的业务动作。比如“用户下单”包含插入订单、扣减库存、生成支付单，这三步必须原子执行，就该放在同一事务中；但“记录用户浏览日志”和下单无关，不应塞进同一个事务。
- 识别业务上的“逻辑单元”：比如转账=查余额+减出账+加入账+记流水，四步缺一不可
- 避免跨服务/跨库强一致性事务：MySQL 本地事务无法保证分布式场景下的一致性，此时应考虑最终一致性方案（如消息队列+补偿）
- 读多写少场景（如报表查询）通常无需事务；纯写操作（如定时归档）可单条语句自动提交，不显式启事务
慎用长事务，及时提交或回滚
事务开启后未提交，会持续持有锁、占用 undo log、阻碍 purge 线程，严重时拖慢整个实例。尤其要防范应用层因异常、网络中断或逻辑缺陷导致事务“悬挂”。
- 设置 wait_timeout 和 interactive_timeout（连接空闲超时），但不能替代应用层主动管理
- 在代码中明确
COMMIT或ROLLBACK，避免依赖连接关闭自动回滚（不可靠且延迟高） - 对可能耗时的操作（如导入大文件、聚合计算），拆分为多个小事务，每批处理后提交
合理使用隔离级别，降低锁冲突
默认的 REPEATABLE READ 在多数 OLTP 场景够用，但若业务能接受“读已提交”的语义（如统计类中间结果），可降为 READ COMMITTED，减少间隙锁范围，提升并发。
- 避免全局设为 SERIALIZABLE：它通过加锁模拟串行，几乎消灭并发，仅适合极少数强校验场景
- 对只读查询，可显式加
SELECT ... LOCK IN SHARE MODE或FOR UPDATE，但务必确认是否真需要锁，而非误用 - 注意 autocommit=1 下，单条 DML 默认自成事务；需多语句协作时，必须显式
BEGIN/START TRANSACTION
监控与识别异常事务
通过系统表和状态变量主动发现粒度失控问题：
- 查长时间运行事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60; - 看锁等待：
SELECT * FROM performance_schema.data_lock_waits;（MySQL 8.0+）或SHOW ENGINE INNODB STATUS\G - 监控 Com_commit 和 Com_rollback 比率，突增的 rollback 可能暗示事务设计不合理
