Tidb索引数据结构（LSM-TREE）

2019独角兽企业重金招聘Python工程师标准>>>

在 TiDB 中，底层索引结构为 LSM-Tree，如下图：

 

开篇

世界级的开源分布式数据库 TiDB 自 2016 年 12 月正式发布第一个版本以来，业内诸多公司逐步引入使用，并取得广泛认可。

对于互联网公司，数据存储的重要性不言而喻。在 NewSQL 数据库出现之前，一般采用单机数据库（比如 MySQL ）作为存储，随着数据量的增加，“分库分表”是早晚面临的问题，即使有诸如 MyCat、ShardingJDBC 等优秀的中间件，“分库分表”还是给 RD 和 DBA 带来较高的成本； NewSQL 数据库出现后，由于它不仅有 NoSQL 对海量数据的管理存储能力、还支持传统关系数据库的 ACID 和 SQL，所以对业务开发来说，存储问题已经变得更加简单友好，进而可以更专注于业务本身。而 TiDB，正是 NewSQL 的一个杰出代表！

站在业务开发的视角，TiDB 最吸引人的几大特性是：

支持 MySQL 协议（开发接入成本低）；

100% 支持事务（数据一致性实现简单、可靠）；

无限水平拓展（不必考虑分库分表）。

基于这几大特性，TiDB 在业务开发中是值得推广和实践的，但是，它毕竟不是传统的关系型数据库，以致我们对关系型数据库的一些使用经验和积累，在 TiDB 中是存在差异的，现主要阐述“事务”和“查询”两方面的差异。

TiDB 事务和 MySQL 事务的差异

MySQL 事务和 TiDB 事务对比

在 TiDB 中执行的事务 b，返回影响条数是 1 （认为已经修改成功），但是提交后查询，status 却不是事务 b 修改的值，而是事务 a 修改的值。

可见，MySQL 事务和 TiDB 事务存在这样的差异：

MySQL 事务中，可以通过影响条数，作为写入（或修改）是否成功的依据；而在 TiDB 中，这却是不可行的！

作为开发者我们需要考虑下面的问题：