事务未提交时数据对其他会话不可见
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。别让它睡着了还赖在数据库里。
