11｜隔离性：读写冲突时，快照是最好的办法吗？

我认为 Spanner 的时钟误差会影响到事务吞吐量： 由于 Spanner 是 External Consistency 的，也就是可线性化（linearizable）的，那么只要两个事务需要读写的数据中有相交的数据，那么它俩的提交时间平均间隔至少是7ms，因为置信区间平均是7ms，那么在这个置信区间内是不能 commint 2 个读写了某个相同数据的事务的，否则就会打破可线性化，因为两个事务不一定分得出先后。因此 Spanner 在单位时间内的事务吞吐量是被时钟误差限制的，时钟误差越小，吞吐量越高，误差越大，吞吐量越低。 并且我也猜测，以下两种情况是的事务吞吐量是不被时钟误差影响的： 1. 如果两个事务操作的是完全不相交的数据，那么它们的 commit time 是可以重合的，因此时钟误差限制的仅仅是操作相交数据的事务的吞吐量。 2. 如果某个事务是只读事务，那么也不受限制，因为只读是基于快照的，其 commit timestamp 并没有意义，因此不需要与读写事务抢时钟。 受限于既有知识，猜测可能有误，仅仅是交流~

tidb不是用raft实现了全局时钟么，为什么不可以用来作全局事务管理？

所以，tidb宣称的高并发，是基于不同的数据？修改同一块数据的话，其实是降的？因为有锁。。。

MVCC 有三类存储方式，一类是将历史版本直接存在数据表中的，称为 Append-Only，典型代表是 PostgreSQL。 ------ 请教老师一下，这个词append-only是专业术语吗？因为我觉得postgresql的mvcc不能说成append-only，这有可能是我对这个名词的理解有问题

我理解pgxc没有在每个数据节点去维护一个活跃事务表，是因为会出现当某个全局事务在commit阶段时候，某个节点已经完成commit，但是整体还没完成的情况下，如果下个事务进来，会读取到已经commit完成节点的数据，但是读不到未完成commit节点的数据。这个时候就有问题了。

感觉这一章有点故意混淆写操作和2PC。TiDB的事务应该只有提交的时候才涉及Prewrite/Commit，而不是每次写操作发生的时候

tidb实现了mvcc，但是使用过程中确实存在读写冲突，一直没想明白，看完这一章内容，理解了。 老师，想问下，tidb既然存在读写冲突，那么select count一张大表时，这张表应该会阻塞写，但是感觉好像没阻塞，这是为什么？ 我想表达的意思是：本文描述的读写冲突原因确实有道理，但是使用时又感觉没那么严重

按照 RC 隔离级别的要求，事务只能看到的两类数据： 1.当前事务的更新所产生的数据。 2.当前事务启动前，已经提交事务更新的数据。 这段描述好像不对吧， 在rc级别下， 当前事务启动后还未提交的过程中， 这时候有个事务开启，然后提交，对当前事务也是可见的

我看到tidb官方文档有说到它实现了可重复读隔离级别 https://www.bookstack.cn/read/pingcap-docs-cn/sql-transaction-isolation.md 如果TiDB 没有设计全局事务列表，它是不是用了别的方式来实现了可重复读的隔离级别；比如通过时间戳的比较来判断两个事务的先后关系。

老师是不是可以这么总结： 1. Append-Only的话，会把同一行的历史数据保存到一张表中，比如User里有个叫张三的，修改了它的值之后就会产生另一行张三，还是在同一个表中。 2. Delta的话，保存增量操作，这些操作存储到一个独立的磁盘空间中，而不是当前的数据表、 3. Time-Travel有点像redo/undo log，记录内存页在物理磁盘上修改前和后的变化