MySQL事务未提交时数据仅当前会话可见，且持续持有锁、阻碍并发、膨胀undo日志、拖慢MVCC性能；须显式提交、缩短事务边界、监控长事务。
事务未提交时数据对其他会话不可见
MySQL 默认隔离级别是 REPEATABLE READ，事务中执行的 INSERT、UPDATE、DELETE 在未 COMMIT 前，只对当前会话可见。其他会话查不到这些变更，也不会被阻塞（除非涉及行锁冲突）。
常见错误现象：
– 你在命令行客户端执行了 UPDATE users SET status=1 WHERE id=100，没 COMMIT，然后用另一个 MySQL 客户端或应用去查，发现数据还是旧值；
– 应用日志显示“更新成功”，但下游服务查不到变更，误以为同步失败。
实操建议：
– 开发调试时，用 SELECT * FROM information_schema.INNODB_TRX 查看当前活跃事务，确认是否有长时间未提交的 trx_state = 'RUNNING'；
– 避免在交互式客户端中执行 DML 后直接退出，MySQL CLI 退出默认不自动提交，会回滚；
– 应用层务必显式调用 commit() 或 rollback()，不要依赖连接池或框架的“自动提交”开关（它只控制新事务的初始状态，不影响已有事务）。
未提交事务会持续持有锁
哪怕只是执行了一条 SELECT ... FOR UPDATE 或 UPDATE，只要没 COMMIT 或 ROLLBACK，InnoDB 就会一直持有对应记录（或间隙）上的行锁或间隙锁。
后果很直接：
– 其他会话尝试修改同一行会被阻塞，SHOW PROCESSLIST 中状态为 updating 或 Locked；
– 若锁等待超时（默认 innodb_lock_wait_timeout = 50 秒），对方报错 ERROR 1205 (40001): Deadlock found when trying to get lock 或 Lock wait timeout exceeded；
– 大量未提交事务可能耗尽 innodb_row_lock_waits 计数器，拖慢整个实例吞吐。
实操建议：
– 在业务逻辑中缩短事务边界，例如：把「查+算+更」拆成「查→应用计算→更」，避免在事务里做 HTTP 调用或文件读写；
– 使用 SELECT ... LOCK IN SHARE MODE 替代 FOR UPDATE，当只需要防止并发修改、不需独占写权限时；
– 监控 information_schema.INNODB_LOCK_WAITS 和 INNODB_LOCKS（MySQL 5.7+ 已弃用，改用 performance_schema.data_locks）。
连接断开或异常终止时事务自动回滚
MySQL 不会保留“半开事务”。只要客户端连接中断（网络闪断、应用崩溃、kill connection），服务端检测到连接关闭，就会立即触发隐式 ROLLBACK。
但注意这个“立即”有前提：
– 必须是正常 TCP 断连或服务端主动检测到（依赖 wait_timeout 和 interactive_timeout 设置）；
– 如果是数据库进程崩溃（mysqld crash），重启后通过 redo log 恢复，未提交事务全部丢弃；
– 如果是主从复制场景，未提交事务根本不会写入 binlog，所以从库永远看不到。
实操建议：
– 不要指望“先改着，等会儿再提交”，尤其在脚本或定时任务中；
– 应用连接池应配置合理的 maxLifetime 和 idleTimeout，避免复用一个挂了很久的连接；
– 使用 SET autocommit = 0 后，必须配对使用 COMMIT/ROLLBACK，不能只靠连接关闭兜底——因为连接可能被复用，事务状态会延续。
长事务导致 undo log 膨胀和 MVCC 性能下降
InnoDB 的多版本并发控制（MVCC）依赖 undo log 保存旧版本数据。只要有一个活跃事务（即使只读），其 trx_start_time 之前的事务产生的 undo 日志就不能被 purge 线程清理。
表现就是：
– information_schema.INNODB_METRICS 中 innodb_undo_log_pages 持续上涨；
– SHOW ENGINE INNODB STATUS 的 HISTORY LIST 长度远大于 1000；
– SELECT 查询变慢，尤其是大表全扫，因为需要遍历更多版本链判断可见性。
实操建议：
– 避免在事务里执行 SLEEP()、用户输入等待、长循环等操作；
– 对只读分析类查询，显式加 START TRANSACTION WITH CONSISTENT SNAPSHOT，然后尽快 COMMIT，而不是用长事务包住整个报表生成过程；
– 定期检查 SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 10，重点盯住 TRX_STARTED 早于 60 秒的事务。
SELECT trx_id, trx_started, trx_state, trx_query, TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) AS duration_sec FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 30 ORDER BY trx_started;
最易被忽略的是：事务是否“活跃”不看它有没有在执行 SQL，而看它有没有提交。一个空闲的、只执行过一条 SELECT 的事务，只要没 COMMIT，照样锁资源、占 undo、拖慢 MVCC。别让它睡着了还赖在数据库里。
