应将非数据库操作移出事务块，仅保留必要sql；批量更新需分批提交（1000～5000行）；读写分离须严格隔离事务内读写；高并发低冲突场景优先用乐观锁替代select for update。
把非数据库操作全移出事务块
事务一旦开启，所有后续语句都在锁保护下执行，直到 COMMIT 或 ROLLBACK。但很多业务逻辑根本不需要数据库一致性保障，比如调用第三方支付接口、写本地日志、发消息队列、格式化返回值——这些操作耗时可能远超 SQL 执行本身，却让锁白白挂着。
常见错误现象：Deadlock found when trying to get lock 或 Lock wait timeout exceeded，查 SHOW ENGINE INNODB STATUS 发现事务卡在“sleeping before sending response”这类状态。
- 反例：事务中先
UPDATE order SET status='paid' WHERE id=123，再调用payService.doPay()（耗时 800ms），最后COMMIT - 正解：只把
UPDATE包进事务；支付成功后异步更新状态，或用最终一致性补偿 - 额外收益：连接池压力下降，
innodb_trx.trx_state中LOCK WAIT状态事务数明显减少
批量更新必须分批次提交
一次性 UPDATE ... WHERE id IN (1,2,...,50000) 看似简洁，实则让 InnoDB 对这 5 万行持续加锁，期间任何对其中任意 ID 的 SELECT FOR UPDATE 或 UPDATE 都会被阻塞。
性能影响很直接：单次事务日志（undo log）暴涨，innodb_row_lock_time_avg 指标跳升，监控里出现大量 Waiting for table metadata lock（其实是行锁等待被误报）。
- 推荐批次大小：1000～5000 行，取决于单行更新复杂度和服务器负载；可先从 2000 测试，观察
SHOW ENGINE INNODB STATUS中的TRANSACTIONS部分锁等待时间 - 安全写法优先用主键范围：例如
UPDATE t SET flag=1 WHERE id BETWEEN 10000 AND 11999，比LIMIT更稳定（避免重复或遗漏） - 务必在每次循环末尾显式
COMMIT，不能依赖自动提交——尤其在存储过程或应用层手动开启事务时
读写分离要真正落地到事务边界
很多团队说“用了读写分离”，但事务里仍混用 SELECT 和 UPDATE，导致主库锁住数据的同时，从库还没同步完，业务又去从库查——看似没锁，实则数据不一致 + 主库锁延长。
更隐蔽的问题是：事务内第一次 SELECT 触发了一致性读（快照），后续 UPDATE 却基于这个旧快照做判断，结果更新了过期数据（典型 ABA 问题）。
- 正确做法：事务只写不读，或只读不写；需要“先查后改”的场景，改用
SELECT ... FOR UPDATE显式加锁，且确保该语句在事务最开头执行 - 隔离级别配合：若业务允许，把
transaction_isolation设为READ COMMITTED，能关闭间隙锁，大幅降低UPDATE范围 - 检查手段：执行
SELECT @@transaction_isolation，确认不是默认的REPEATABLE READ；线上环境建议统一配置而非代码里动态设
用乐观锁替代 SELECT FOR UPDATE 的真实条件
SELECT ... FOR UPDATE 是强一致性保障，但代价是立即加锁、阻塞其他事务。它只应在“极大概率发生并发写冲突”时使用，比如秒杀库存扣减。多数业务场景其实冲突概率低，硬上悲观锁反而制造瓶颈。
容易踩的坑：在用户中心类服务里，对 user_profile 表频繁用 FOR UPDATE 更新昵称/头像，结果一个慢查询拖垮整张表的并发更新能力。
- 适用乐观锁的信号：表有
version或updated_at字段；冲突后重试成本低（比如前端提示“他人已修改，请刷新”） - SQL 写法示例：
UPDATE user SET name='new', version=version+1 WHERE id=123 AND version=5；检查ROW_COUNT()是否为 1，为 0 则说明已被别人抢先更新 - 注意点：乐观锁不能防止幻读，也不适用于“必须保证中间状态不被读到”的场景（如金融记账）
