MySQL数据清洗到TiBD

一、业务背景

公司主要做的业务是类似贝壳的二手房租售，数据库中存了上亿级别的房源数据，之前数据库使用的是 mysql，后面需要将 mysql 数据库切换成了 Tidb，在切换的过程中，需要将老库的数据经过数据清洗后再存入新库（因为有一些表结构的设计变了），其中我们处理的一个逻辑就是将房间下业主信息从老库清洗到新库：我们需要按照城市维度，查询新库所有的房间，然后拿着新老库的房间对应关系，再到老库中找到所有对应的房间，然后通过房间再找到每个房间对应的业主信息，最后将业主的不同维度信息（一共5个维度信息）清洗到新库的不同数据表中。

下文我就简单描述一下数据清洗过程中遇到的各种问题以及解决方案，所有问题都会附上真实的案例和说明。

二、从问题入手选定处理方案

问题

• 在清洗过程工，我们无法将某个城市的几百万甚至上千万的房间信息一次性查询出来，再去找所有房间的业主信息，这样内存肯定会撑爆；
• 数据清洗过程中肯定不能一条一条的新增数据，这样的话几百万（举例300W）的房间数据，有5个维度需要新增数据，那么就会一条一条的新增300W房间对应维度的数据，就会操作 300W*5 次，效率低下；
• 数据清洗后批量插入新表的时候也不能一次性插入300W（每个表插入300W，5个维度分别插入5个表，即插入5次300W的数据）。

方案

先查询出需要清洗的数据总量，然后按照某个量（比如：1000条）进行分页查询出具体的数据，然后清洗这1000条房间对应维度的数据并插入新库中，再清洗下一个1000条数据，直到把所有数据清洗完成。

三、批量查询确定效率最优数量值

在上面处理方案出来后，下面就是在程序开发过程中遇到的一些具体问题，分页查询的逻辑其实就是常用的 SQL 的 limit m, n，通过 page 和 pageSize 来进行分页查询，再使用 limit m,n 进行分页查询的时候又遇到下面几个问题：

• 分页查询查询和处理新增数据，按照多大的量来进行分页查询，是一次性查询5000条房间还是1000条房间来处理对应数据的清洗，使得查询和处理的效率最高效？
• 如果一次性查询和处理较少的数据量，比如每次分页查询出100条数据来进行清洗，如果某城市有800W的数据，分页查询需要查询处理80000次，这个处理次数是否过多？
• 使用常规的 limit m,n 的方式进行分页查询，那么越查询到靠后的页数（ limit m,n 语句的查询时间与起始记录的 m 位置成正比）查询就会变得越慢，如何处理？

注：下面所有的数据都是在公司的机器上面得出的效率数据，大家在使用的时候以实际为准，这里只是提供解决思路

1、批量插入最优值寻找过程

下面先附上一张我们和DBA的聊天来引出问题：

公司大量业务都开始使用TiDB，很多数据都需要从MySQL迁移到TiDB，在迁移过程中，批量新增都会遇到一个问题，就是随着批量新增的数据量变大，耗时巨慢，DBA说的是100条以内就非常快，那么这个条数多少条对于我们业务处理是最合理的啦？下面就是一个论证过程。

下面直接上数据，后面会对数据进行说明：