背景随着时间的推移交易系统中的订单表越来越大目前达到500w数据。为了防止数据量过大导致的查询性能问题现将订单表进行拆分分为实时库和历史库。实时库保留近6个月的数据用于退款业务需求其余订单数据全部迁移到历史库中。方式一复制表结构与数据可通过navicat右键选择复制表结构与数据进行全量同步数据。但是该操作会锁表导致其他事务的新增、修改、删除操作都被挂起慎用方式二dbf文件方式导入导出数据可通过navicat菜单进行dbf格式导出。此操作数据完整性最高导出文件大500w数据可达到30G不锁表导出过程中可新增、修改、删除。测试500w数据导出时间30min导入时间字段映射存在问题导入失败方式三txt文件方式可通过navicat菜单进行txt格式导出。数据完整性中等导出文件不大500w数据不到1G;不锁表。测试500w数据导出时间8min导入时间约2h方式四导入导出命令推荐注意当前用于需要有该导入导出命令权限。导出时不锁T_UNION_ORDER表select * from T_UNION_ORDER into outfile b.txt;导入时锁T_UNION_ORDER_copy1表load data infile b.txt into table T_UNION_ORDER_copy1;测试500w数据导出时间1min导入时间8min方式五程序迁移推荐先插入数据到新表中再删除原表数据两组操作作为一个事务来处理。可参考以下步骤执行步骤一定时任务开启时间2点~3点 1小时内每10s触发一次同步任务。步骤二一个批次的数据量为300条1h同步10.8w条数据。insert_time 条件值取第前180天。insert_time没有创建索引走的全表扫描sql语句耗时时间和符合条件的记录条数占全量数据的百分比相关占比越大耗时越短占比越小耗时越长。因此程序上线初期一次同步任务的执行时间较短后期随着需要同步的数据越来越少sql执行的时间也越来越长。select * from T_UNION_ORDER where insert_time 2023-01-01 00:00:00 limit 300;批量进行数据插入一个批次的数据量要适中太大会导致字符串长度超长报错太小频繁访问数据库导致可能的性能问题。insert into T_UNION_ORDER_HISTORY () values (),(),();批量删除删除操作会加锁。虽然是行锁如果in的数据量太大可能会造成索引失效行锁升级为表锁。delete from T_UNION_ORDER where order_no in ();步骤三增加手工触发订单数据同步机制。