每月1号凌晨跑job
如果没有创建时间筛选，扫描所有表join
如果减少join的语句？用id查询数据的时候，不可避免的要扫码所有的分表。这个怎么优化？
承担数据迁移
step3 程序改造
所有表和数据全部准备完毕
修改程序-shardingcore
数据迁移完成的过程中，可能正好数据访问，这个时候怎么办？时长可能需要10分钟。好在迁移的是半年的数据，被使用的概率不高，出错查不到能被接受。
所有设计拆分表的查询中都要尽可能加上创建时间筛选
只有原始表是自增的，其他分表无法自增？
准备拆表
step1 数据准备
更新split_table_info的任务
ETL清洗数据
设置拆分表的路由规则
在数据迁移过程中，可以根据情况修改查询逻辑，使得查询既能够查询原表，也可以查询新表。这样可以确保无论数据位于哪个表，查询依然可以得到正确结果。？shardingcore是否支持呢？
三方批处理对象需要获取真实dbcontext后才可以支持
CRUD风险
step2 定时任务
更新程序中的表后缀信息？这个怎么刷新最快呢？引入Redis？MemoryCache 选这个？
两张表join，如果都分表了，怎么办呀？时间只传了一个表的创建时间过来，如果要查两个表，会可能导致数据丢失。因为两个时间可能不是刚好都在一个半年区间内的。 当3个4个分区表的时候，查询会非常慢，很夸张？官方：不建议使用join，否则笛卡尔积，增加很多数据库连接，非常恐怖
