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