用按键精灵做网站软文云

-- 开启一个事务，但不执行写操作
START TRANSACTION;
-- 查询 InnoDB 事务信息
SELECT * FROM information_schema.innodb_trx;

在 MySQL 的 MVCC (多版本并发控制) 中，事务 ID (Transaction ID) 是由 InnoDB 存储引擎分配的，它的分配机制与事务的读写操作紧密相关。

事务 ID 的分配规则

1. 事务启动时：

   • 当一个事务开始时，InnoDB 并不会立即分配事务 ID。
   • 只有当事务执行了 INSERT、UPDATE、DELETE 或任何其他修改操作时，InnoDB 才会从事务系统中获取一个唯一的事务 ID。

2. 纯读事务的情况：

   • 如果一个事务仅执行了读操作（例如 SELECT），且是基于快照读 (Snapshot Read) 的场景，事务不会分配一个事务 ID，而是使用一个特殊的标记来维持当前读视图 (Read View)。
   • 在这种情况下，事务会基于快照中的数据一致性来处理读请求，而不依赖事务 ID。

3. 显式分配事务 ID 的时机：

   • 普通读操作 (Snapshot Read)：不会分配事务 ID，只生成一个当前快照的读视图。
   • 一致性锁读 (SELECT ... FOR UPDATE/LOCK IN SHARE MODE)：需要事务 ID。
   • 写操作 (INSERT/UPDATE/DELETE)：需要事务 ID。

关于 Read View 的事务 ID

对于一个未执行任何 INSERT、UPDATE 或 DELETE 的事务：

1. 未分配事务 ID：因为事务未触发修改操作，InnoDB 不会分配事务 ID。
2. Read View 的内容：
   • read view 中会保存一个事务快照的状态，但这个快照不依赖于事务 ID，而是基于系统中的活跃事务列表 (trx_ids 集合) 来判断数据的可见性。

实验验证

可以通过以下步骤验证：

-- 开启一个事务，但不执行写操作
START TRANSACTION;
-- 查询 InnoDB 事务信息
SELECT * FROM information_schema.innodb_trx;

在这种情况下，查询结果中 不会有事务 ID，直到你执行写操作为止。

总结

对于没有执行 INSERT、UPDATE 或 DELETE 的事务，其 read view 中不会包含自身的事务 ID，因为事务尚未分配事务 ID。Read View 依然基于当前系统的活跃事务列表生成，用于保证读取一致性。