跨三个 TiKV 的一次转账，凭什么"要么全成、要么全不成"
让另一个事务 T2 抢先提交、改掉同一个 Key，然后看 T1 走到 prewrite 时会发生什么。
start_ts（同时作为 MVCC 快照版本）→ 读请求 → 写请求先存入该事务的私有内存 → 选出一个 Key 作为 Primary Key → 并发向所有涉及的 TiKV 发 prewrite（TiKV 检查版本冲突或过期，通过者被加锁）→ 收到全部 prewrite 成功响应 → 向 PD 取 commit_ts → 向 Primary Key 所在 TiKV 发起 commit 并清理 prewrite 留下的锁 → 返回成功，随后异步清理遗留锁信息。scheduler-concurrency 默认 2048000（scheduler 内置内存锁，防止同时操作同一个 Key）；单事务大小上限 100 MB（txn-total-size-limit，最大支持 1 TB）；单行上限 6 MB；单事务键值对数量限制自 v4.0 起取消。start_ts = 100 / commit_ts = 200 为示意编号，真实环境中是 PD 分配的全局唯一递增 TSO，并非从 1 开始计数。以上带虚线的条目均可点击，查看官方原文、适用版本与文档链接 —— 琥珀色虚线表示"官方未列明，因此本作品一个字都不写"。