MySQL Session间事务完全隔离，根本原因是InnoDB的ReadView快照机制：每个事务首次读时生成只读快照（含活跃事务ID列表、上下限ID），后续读均基于该快照判断版本可见性；Session B未提交的变更其trx_id必在Session A的m_ids中，故判定不可见。
MySQL 本身不支持跨 Session 的事务可见性“共享”——每个 Session 的事务是完全隔离的，这是由 MVCC 和 ReadView 机制决定的，不是配置或代码能绕过的。
为什么 Session A 看不到 Session B 未提交的 UPDATE/INSERT
根本原因在于 InnoDB 的 ReadView 快照机制：每个事务在第一次执行 SELECT（或 UPDATE/DELETE 的读取阶段）时，会生成一个只读快照，记录当时所有活跃事务 ID 列表（m_ids）、已提交事务上限（up_limit_id）和未创建事务下限（low_limit_id）。之后所有读操作都基于这个快照判断版本可见性。
Session B 插入或修改的行，若其 trx_id 在 Session A 的 ReadView.m_ids 中，就会被判定为“不可见”，哪怕 Session B 已执行 UPDATE 但尚未 COMMIT。
- 这不是延迟或缓存问题，而是设计行为
-
SELECT * FROM t不会“刷新”当前事务的 ReadView；只有新事务或显式START TRANSACTION WITH CONSISTENT SNAPSHOT才会重建 - 即使 Session B 已
COMMIT，Session A 在可重复读（RR）级别下仍看不到——除非它执行新查询且隔离级别是读已提交（RC）
如何让 Session A “感知”到 Session B 的变更
关键取决于你的目标场景：是调试验证、业务协同，还是规避幻读？没有通用解法，只有针对性策略：
- 如果只是想确认变更是否生效：
SELECT前在 Session A 中执行COMMIT再START TRANSACTION，或直接用SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED后重连 - 如果要等待 Session B 提交后再继续：
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE会阻塞直到 Session B 提交（但仅对已存在记录有效；对 INSERT 的新行需配合唯一索引+重试） - 如果涉及业务级协同（如订单锁库存），不要依赖“可见性”，改用显式加锁：
UPDATE stock SET qty = qty - 1 WHERE sku = 'X' AND qty >= 1，靠影响行数（Rows matched）判断是否抢到 - 避免在 RR 级别下依赖“查不到就插入”的逻辑（
INSERT IGNORE或ON DUPLICATE KEY UPDATE更安全）
容易踩的坑：误以为 SET autocommit=0 能跨 Session 生效
autocommit 是 Session 级变量，只控制当前连接的默认提交行为。设成 0 后，你仍无法看到其他 Session 的未提交数据——它只影响“你自己事务何时自动结束”，不影响“你能看到谁的数据”。
常见错误包括：
- 在 Session A 中反复
SELECT等待 Session B 提交，却忘了 Session A 自身处于 RR 级别，快照已固化 - 用
mysql -u user -p -e "SELECT ..."临时命令查数据，误以为这是“同一个 Session” - ORM（如 MyBatis）中
openSession(false)创建的 Session 与业务线程绑定，但多个 HTTP 请求共用同一 Session 实例，导致 ReadView 意外复用 - 在存储过程中调用
SELECT，却没注意该过程运行在调用者的事务上下文中，快照继承自外部 Session
真正需要跨 Session 协同的场景（比如分布式任务协调），MySQL 原生事务机制无能为力；得靠外部手段——应用层轮询 + 版本号字段、Redis 分布式锁、或专用消息队列通知。InnoDB 的隔离边界非常清晰，越想“穿透”，越容易掉进一致性陷阱。
