mysql默认隔离级别为可重复读（repeatable read），未提交事务的数据仅对当前会话可见，其他会话查不到，这是mvcc机制保障的正常行为，非bug。
默认隔离级别下，未提交事务的数据对其他会话不可见——这不是 bug，是 MySQL 的正常行为。
为什么 SELECT 查不到自己刚 INSERT 的数据？
常见现象：在同一个 MySQL 客户端里执行 INSERT 后直接 SELECT，能查到；但换一个客户端（或新连接）执行同样的 SELECT，却查不到。这往往不是“没插入成功”，而是事务还没 COMMIT。
根本原因在于：MySQL 默认使用 REPEATABLE-READ 隔离级别，它通过 MVCC（多版本并发控制）保证每个事务看到的是一致的快照。未提交事务产生的变更，只对本事务可见，其他事务看不到，也不会触发脏读。
- 除非显式开启事务（
BEGIN或START TRANSACTION），否则每条语句默认自动提交（autocommit=1） - 一旦手动开启事务，后续所有 DML 都进入“未提交状态”，直到你执行
COMMIT或ROLLBACK - 其他连接即使执行
SELECT，也只会读取该事务开始前已提交的数据版本
如何确认当前有未提交事务？
直接查系统表最可靠：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM INFORMATION_SCHEMA.INNODB_TRX;
重点关注 trx_state = 'RUNNING' 且 trx_started 时间很早的记录——说明这个事务挂了很久，可能忘了 COMMIT。
- 如果
trx_state是LOCK WAIT，说明它正被锁阻塞，需要结合INNODB_LOCK_WAITS查谁在持锁 -
trx_mysql_thread_id可用于后续KILL操作（如KILL 12345） - 注意：
SHOW PROCESSLIST只显示线程状态，不体现事务是否提交，不能替代INNODB_TRX
想让其他会话“立刻看到”未提交数据？别这么做
技术上可以通过降级隔离级别实现，但强烈不建议：
-
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;后再SELECT，确实能看到未提交数据（即允许脏读） - 但这是反模式：业务逻辑依赖未提交状态极易出错，比如读到随后被
ROLLBACK掉的数据 - 绝大多数场景应靠明确的
COMMIT时序 + 应用层状态同步来协调，而不是绕过隔离机制 - 真正需要跨事务感知的，应该用消息队列、binlog 订阅或应用层事件通知
容易被忽略的关键点
事务可见性不是“网络延迟”或“缓存没刷”，而是引擎层的确定性行为。排查时最容易踩的坑是：
- 误以为
autocommit=1就绝对安全——其实只要手动BEGIN了，就进入手动事务模式 - 在 ORM（如 Django、SQLAlchemy）里启用了事务装饰器或上下文管理器，但忘记
commit()或save()调用 - 连接池复用连接后，上一个请求留下的未提交事务污染了下一个请求（尤其在长连接 + 无事务清理逻辑时）
- 用
SELECT ... FOR UPDATE锁行后没及时COMMIT，导致后续操作被阻塞且难以定位
