直接回答：大事务（执行时间长、修改行数多）是典型的生产隐患：一是长时间持有行锁和 MDL 锁，阻塞并发、放大死锁概率；二是 read view 不释放，undo log 无法被 purge，旧版本堆积导致 undo 表空间膨胀、MVCC 版本链变长使普通快照查询变慢——监控指标是 history list length 飙高；三是 binlog 在提交时一次性写入，造成主从延迟陡增；四是回滚代价与执行代价相当，一旦中断雪上加霜，回滚期间线程还占着不放；五是长期占用连接和 Buffer Pool 资源，压垮连接池。

实践要点：核心是把事务做小做短：先查询后开启事务，事务内只放必须原子执行的写操作；远程调用、消息发送、文件操作一律挪出事务。批量更新分批提交，每批 500～1000 行，用主键范围或 LIMIT 切片，批间可加短暂 sleep 给从库追赶。监控上用 information_schema.innodb_trx 找长事务，用 performance_schema 定位来源 SQL 和具体会话，必要时直接 KILL 掉；开启 innodb_undo_log_truncate 控制 undo 表空间大小，配合监控 history list length 判断 purge 是否积压。业务上能用对账加补偿就不要用“巨型事务”。

-- 找出执行超过 60 秒的事务
SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_started < NOW() - INTERVAL 60 SECOND;

追问方向：为什么一个长事务会让全库的历史查询都变慢？事务里调 RPC 为什么危险？分批提交破坏了原子性怎么办？ （约 356 字）