mycat是分库分表不是分布式数据库。
tidb是不需要分库分表的一个大的数据库。是分布式数据库。
tbase没有了合并到tdsql了。是分布式数据库。
分布式数据库和分库分表的区别是全局事务，分布式索引，分布式排序。数据库集群给你控制，不是由应用或者框架控制。

TBase是基于PostgreSQL开发的企业级分布式HTAP数据库，这里介绍下TBase在分布式事务方面的一些经验：

传统基于MVCC+2PC+GTM做的分布式事务，在高并发的情况下这种基于GTM全局快照的设计会在GTM上有比较大的性能压力。一个是GTM加锁遍历生成全局快照中活动事务列表计算的开销以及锁冲突开销，另一个是高并发下活动事务列表过大导致快照大小膨胀带来的网络开销。这两点导致这种设计在高并发情况下性能受限。

Google Spanner基于原子时钟和true time api实现了一致性的分布式事务，但需要昂贵的设备支持。Google Percolator采用全局时钟提供一致性分布式事务，但

Percolator在一阶段提交时需要遍历数据将锁信息写入到数据单位，二阶段时又需要遍历数据释放锁写入提交时间戳等信息。事务提交开销变大且与数据量相关。

TBase在参考Spanner/Percolator的基础上，为避免上述性能问题，创新性的结合MVCC+2PC提出了一种轻量级的基于全局时钟（GTS）的一致性分布式协议及算法。主要思路是在两阶段提交中的prepare阶段作为全局同步点结合GTS的原子递增性保证多节点间的数据一致性和隔离性。基本消除GTM的网络开销问题，并将GTM单点压力分散到分布式多节点中。

主要从以下几个方面进行优化：
MVCC从基于全局快照事务ID+事务状态的可见性判断，优化为基于GTS+事务状态的可见性判断
在当前节点prepare到收到commit通知之前会有事务锁保证全局一致
为了避免Percolator的提交开销变大的情况，TBase在提交时只记录一次事务提交GTS到时间戳日志，避免提交开销。
后续进行可见性判断时，结合时间戳日志判断事务状态，且对时间戳日志进行缓存加速。随后在tuple的header记录中缓存事务状态及提交GTS信息，进一步加速后续扫描的可见性判断。

TBase同时对MVCC空间回收进行改造，融入到基于GTS的一致性分布式事务中。
优化后GTM只负责分配全局时间戳，且设计了一种多核可扩展的全局原子递增时间戳算法进一步提高单点GTS分配性能。
欢迎大家进一步深入交流