OB大表在需要归档的数据大概在1亿左右时往历史库中写入数据和源库在做数据删除时是否会对线上租户产生影响，按照传统的MySQL归档的pt工具，MySQL是按照查询条件会分批(比如limit 1000条)查询出数据的主键ID，然后通过主键ID进行数据删除，这就要求在查询条件上需要相应的索引，否则，表过大时查询非常消耗实例性能，希望OB这边能给点相关说明解释一下归档逻辑。
在读处理时首先会将表按主键拆成多个分片。对于每个分片，读数据时基于主键范围、批次大小及查询条件进行查询，其中单条 SQL 的处理批次大小默认为 200，读线程数默认为 6。在删数据时，将上述读到的数据，按主键 ID 进行分批删除， 删除时批次大小默认为 100，处理线程数默认为 6。以上参数均可 ODC 元数据库中修改。
产品功能使用： 数据归档-OceanBase 开发者中心-OceanBase文档中心-分布式数据库使用文档
使用条件里要求表有主键，要求指定归档触发条件（一般是状态列或时间列），由此推测ODC归档内部逻辑本质上也是数据搬迁。先单独查出一大批主键，然后把这批主键拆分给多个线程去搬迁数据（select，insert，delete）。前面的查询由于并发很低，不需要单独建索引。使用SQL的并行技术，也不会太慢。即使慢也无所谓，耗时的是后面具体数据的搬迁。
当然，如果有索引肯定会更好。索引是为业务重要查询场景服务的。索引太多对写不友好。建不建索引看哪个场景更重要。历史数据归档任务在晚上低峰期慢慢跑，对业务影响也小。
上面是猜测和分析。如果想知道ODC数据归档逻辑，自己造一个大表，启用数据归档。同时开启OB的SQL审计功能（租户参数 enable_sql_audit 设置为true），捕捉一下数据归档的SQL就知道原理了。
另外，ODC 也开源了，也许开源代码里会有。