我先说几个最让你兴奋和开心的点吧：
在TiDB里，你完全不用担心磁盘容量的问题。
在TiDB里，原生支持OnlineDDL，你完全不用担心第三方改表工具改表出现各种Bug的问题，相信用开源工具改过上T级别表的同学都遇到过或多或少的各类error。
在TiDB里，加列，主键扩容字段都是秒级的，比如我刚刚就刚对一张19亿的表加完了字段，1秒完事，这在MySQL里要8.0才可以，而且还要求列在最后才行。
在TiDB里，你会发现count(*)惊人的快，一张近20亿的表coun(*)大概在1分钟完事儿，当然，这取决于你的KV数量和磁盘性能。
在TiDB里，从MySQL迁移将变得简单，图形化一键迁移，爽不爽？
在TiDB里，绝大多数情况你会发现比单机MySQL有更好的性能，当然也不排除一些例外，例如enum这样奇葩的字段类型。
在TiDB里，......，您且往下看，我慢慢和您说。
使用背景
60云平台对60集团各大业务线均有提供服务支持，涉及的数据库支持方案有：MySQL、Redis、MongoDB、ES、GP、PiKA。其中MySQL至今已有过万的实例，目前，对于一些写入量大的业务，已经出现瓶颈。例如磁盘空间，虽然我们可以通过分库分表的方式，拆分出来，但这对业务和DBA来说都是不小的工作量，最痛苦的无异于这些大表的改表。无论是单表上T，还是分库分表，对一张大表执行DDL的代价是非常大的。针对业务爆发式增长的数据量，我们开始调研选型是否有其他数据库可以代替传统的MySQL。通过调研我们了解到TiDB，迁移平滑，基本上无需业务变动代码，完全的事务ACID支持，分布式的架构，自带高可用、OnlineDDL。截止目前，60云平台这边有三套TiDB集群，总节点数在50+。有9个业务线接入使用，有过百亿级表Online加索引的案例，总数据量目前在80T。版本上，我们从.0.1一路跟随到.0.5，DM版本从内测到1.0.2GA版本，共计提出9个Bug或改进项反馈。后续我们计划将TiDB上到60HULK云平台上，并定制化开发一些功能为业务提供可视化的服务，以便让60集团更多的业务线接触到TiDB、使用TiDB。版本的选择我们之所以从大版本开始，也是看到了一些2.X版本的社区反馈，尤其是索引执行计划这块，.X版本较之前的版本会好很多。DM版本我们是直接选取的最新版，后一路跟随新版本升级。集群架构
整体架构上，我们除了TiDB集群外，还用到了DM和Pump、Drainer套件。这块主要是由于我们使用TiDB的业务有两种：①老的MySQL业务，因单机磁盘受限，导致单实例磁盘无法支撑爆炸式增长的数据量，数据比较重要，需要备份和支持7*2小时的恢复。这类业务我们用到DM套件来实现无障碍迁移，1TB的导入时间在16小时，这里如果是比较大的数据源，且TiDB是全新集群，可以使用TiDB-Lightning，速度可以更快。Lightning的实测导入速度，7分钟，导完2张大表共计5G的数据，符合G/H预估，是loader的倍速度，loader用时2小时分钟。说起DM使用这块文章后面会单独分享下这块需要注意的问题，如下图所示：
②全新的业务，或由业务自行导入到TiDB集群中，这种业务数据量一般都会比较大，也是看中了TiDB支持ACID和分布式的特点。目前网盾业务有多张表都过10亿级别，其中有张表到达了亿+，建索引花了近10天（这块其实我们应当注意，不是分布式就一张表就完事儿了，因为表量级过大，清理老旧数据都是个问题）。TiDB现在支持分区表，但我们在使用过程中发现性能上和普通表有差距，期待后续版本能够让分区表功能和性能更加的完善。TiDB在60云平台的使用情况
对于这一全新的数据库，我们本着大胆用，不拘泥于传统的态度进行使用。我们的MySQL现在也正在适配8.0版本，MongoDB、ES也都是时刻