*TPC Benchmark™H（TPC-H）是决策支持基准。它由一套面向业务的临时查询和并发数据修改组成。选择查询和填充数据库的数据具有广泛的行业范围相关性。该基准测试说明了决策支持系统，该系统可检查大量数据，高度复杂地执行查询并为关键业务问题提供答案。
异常测试: 我们测试了PD、TiKV异常宕机情况下的表现，对业务影响很小，可实现自动故障恢复。
四、迁移方案4.1 迁移前需要解决的问题在真正的数据迁移之前，我们还有一些实际问题需要解决：
SQL Server 和 TiDB 的部分字段类型是不一样的，通过查阅相关文档，将不同的字段一一对应后再在TiDB中建表，例如DATETIME的精度问题。
同步时将分库分表的数据合并到一个表里，值得庆幸的是原有设计中，我们除了自增主键 ID，还有一份业务 ID，其在各个表中均不重复，这样省了不少事情。
一次性导入十亿级数据以及后续增量同步的过程中，如何保证数据的一致性。
如果TiDB在生产时出现了不可预估的问题，一时无法解决，那我们必须立刻切换到SQL Server，保证业务不受影响。换句话说，在TiDB中产生的数据需要实时同步回SQL Server。
因为访问量比较大，切换时间必须控制在秒级。
因为SQL Server是商业数据库，跟开源数据库进行数据同步的方案较少，所以同步方案、架构设计、研发、测试必须我们自己解决。
下面会详细介绍全量和增量同步的实施方案。
五、全量同步
首先我们要感谢以下两个开源项目，站在巨人的肩膀上使我们节约了很多时间。
https://github.com/alibaba/yugonghttps://github.com/alswl/yugong
愚公是阿里巴巴推出的一款Oracle数据迁移同步工具，而作者alswl在此基础上实现了SQL Server数据源的支持。
在此愚公的使用方法我们不再赘述，感兴趣的同学请自行查看。
在认真拜读了大神的项目，并进行了相关测试后，发现它并不能100%满足我们的需求。
Yugong 数据流是标准 ETL 流程，分别有 Extractor、 Translator、Applier 这三个大类来实现 ETL 过程。
首先讲Extractor，愚公原有的配置方式是将需要导出的库表写在配置文件当中，这对于1000+张表来说，太不现实了。这里我们增了一个新特性，在不配置需要导出的表名的情况下，将数据库中所有的用户表读出来，并通过一个新增的配置项进行正则匹配，以此决定哪些表需要进行数据同步。
#查询表SELECT name FROM sys.databases WITH (nolock) WHEREstate_desc = 'ONLINE'#查询开启CDC的表SELECT name FROM %s.sys.tables t WITH (nolock) JOIN%s.[cdc].[change_tables] ct WITH (nolock) ON t.object_id = ct.source_object_id