企业官网建设流程全解析

影刀RPA实操指南：数据库定时清理与归档——老数据搬去备份表

主表越长越大，是每个用影刀RPA做采集的人早晚要面对的问题。我自己的采集表只进不出，攒了半年到了八百万行，入库存入一的数据突然从2秒变成40秒，排查了半天发现不是影刀RPA的问题，是表本身太肥了。解法很简单：把老数据定时搬去备份表，主表只留近期数据。

这篇实操指南给出完整的清理归档方案：SQL怎么写、影刀RPA里怎么排流程、怎么用计划任务让它每天自动跑。所有SQL都能直接抄。

先想清楚：归档不是删除，是搬家

清理老数据有两种做法，直接DELETE和先INSERT再DELETE。我强烈建议后者，理由很朴素：万一WHERE条件写错了，数据从备份表还能捞回来，直接删就真没了。

整个归档逻辑三步：

1. 从主表SELECT出符合"老数据"条件的结果
2. 把这批数据INSERT进结构相同的备份表
3. 确认备份成功后，DELETE主表里对应的数据

备份表必须先建好，字段和主表一模一样。用这句建表语句抄改就行：

-- 建备份表：LIKE会复制goods表的全部字段结构，不含数据CREATETABLEgoods_archiveLIKEgoods;-- 查一下主表和备份表各有多少行，归档前后用来核对SELECTCOUNT(*)FROMgoods;SELECTCOUNT(*)FROMgoods_archive;

核心SQL：搬家三连，直接可用

假设归档规则是：把90天前的数据搬去备份表。三句SQL按顺序放进影刀RPA的三个【执行SQL语句】指令里：

-- 第1句：把主表90天前的数据插进备份表-- INSERT INTO ... SELECT 是"查询结果直接灌进另一张表"的写法INSERTINTOgoods_archiveSELECT*FROMgoodsWHEREcollect_time<DATE_SUB(CURDATE(),INTERVAL90DAY);-- 第2句：核对两边的行数是否一致（把两个COUNT的差算出来）SELECT(SELECTCOUNT(*)FROMgoodsWHEREcollect_time<DATE_SUB(CURDATE(),INTERVAL90DAY))![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/d928855366dd488cafb277cd398da12a.png#pic_center)AS待删行数,(SELECTCOUNT(*)FROMgoods_archive)AS备份总行数;-- 第3句：核对无误后，删掉主表里的老数据DELETEFROMgoodsWHEREcollect_time<DATE_SUB(CURDATE(),INTERVAL90DAY);

DATE_SUB(CURDATE(), INTERVAL 90 DAY)就是"今天减90天"，不用自己算日期，这句是MySQL内置写法。如果你们的规则不是按时间而是按状态，比如status = '已完成'的老订单，把WHERE换成对应条件即可。

我在这里踩过一个真实的坑：归档和删除的WHERE条件看似一样，但如果第1句和第3句之间主表恰好又写入了新数据，条件窗口一致就没事；可我有一回把删除语句里的90天手误写成了9天，直接删掉一批不该删的。所以第2句的行数核对不是可选项，是必选项。

影刀RPA流程怎么排：核对逻辑交给机器人

三句SQL手工跑也行，但归档这种事就该让影刀RPA全自动。流程结构如下：

1. 【连接数据库】指令，连接字符串配置好，保存为db_conn
2. 【执行SQL语句】跑第1句INSERT SELECT，结果存insert_result，取insert_result[0][0]得到插入行数（UPDATE/INSERT/DELETE没有结果集，受影响条数就在第0行第0列）
3. 【执行SQL语句】跑第2句COUNT核对，结果存check_result
4. 【If条件判断】比较两个行数是否相等
5. 相等→跑第3句DELETE，【打印日志】记录"归档完成，迁移N行"
6. 不相等→【打印日志】输出告警，跳过删除，等人工检查
7. Finally块放【关闭数据库】

# 场景：影刀RPA里用Python模式做行数核对，比If指令拼条件更直观# 输入：insert_count为INSERT返回的插入行数，check_count为COUNT查询结果# 输出：return "OK" 表示可以安全执行DELETEdefmain(args):ifinsert_count==check_count:return"OK"else:# 行数对不上，绝不删除，打印差异等人工处理print("行数不一致，插入%s，核对%s"%(insert_count,check_count))return"STOP"

行数核对这道保险，是我用一次惊险事故换来的习惯，你们直接抄走。

大批量归档：分批搬，别一口吃成胖子

百万行级别的归档，一句INSERT SELECT会让数据库长时间高负载，甚至锁表影响采集流程写入。分批搬才稳：

用LIMIT分批的循环逻辑：影刀RPA里While条件循环，每次INSERT SELECT加LIMIT 50000，DELETE同样加LIMIT 50000，循环条件判断本次迁移行数是否为0，为0就退出。每一批之间【等待】1秒，给数据库喘口气。

其他模块在这条业务里的位置

归档流程不大，但把影刀RPA各模块的能力都用到一点，顺手串一遍。

认识与安装。还没装的朋友，影刀RPA官网下载客户端，安装后按提示装浏览器插件，指令面板在左侧，搜索"数据库"就能看到【连接数据库】【执行SQL语句】【数据库批量插入数据】【关闭数据库】这四条核心指令。社区版免费，每天30分钟运行时长，归档流程通常几分钟就跑完，完全够用。

元素定位与网页自动化。归档本身不碰网页，但归档告警如果要做"打开数据库监控页面截图存档"，就涉及元素捕获、XPath和CSS选择器的选择：监控页是简单图表页，CSS选择器div.metric这种短写法足够；要抓表格里特定单元格就用XPath属性定位。弹窗处理记得按"判断存在→点击关闭→继续"的五步标准流程走。

变量与流程控制。归档流程的核心变量就三个：连接对象db_conn、插入行数、核对结果。类型都是list或字符串，取值前判断长度。流程控制用While做分批循环、If做核对判断、Try-Catch兜底，这三样齐了流程就不会跑飞。

数据处理。这篇的主场。除了上面的三连SQL，再补一个删除重复数据的场景：采集重跑导致主表出现重复行，用这句去重（保留每组里id最大的一条）：

-- 删除重复行：按shop+title分组，每组只留id最大的一条DELETEg1FROMgoods g1JOINgoods g2ONg1.shop=g2.shopANDg1.title=g2.titleANDg1.id<g2.id;

鼠标键盘图像与进阶技能。基本用不上图像识别，但Python协同值得提一句：分批循环的行数计算、日期推算，用Python模式写比指令拼接清爽。OCR只在你想把旧备份Excel的截图数据搬进库时用得到。ADB手机自动化与此无关，知道有这回事就行。

平台实战与系统联动。我的小红书采集表和拼多多价格表各自配了一个夜间归档计划任务，凌晨3点跑，错开采集高峰。云端控制台发布计划任务给机器人执行，在任务监控页面设置告警邮箱和钉钉、企业微信、飞书通知，归档异常会自动推消息，不用天天盯。个人版就用客户端的计划任务配置，效果一样。

工程化规范。归档流程独立成一个应用，命名如030_数据归档，和采集、查询流程分开。SQL语句写在指令里时，语句开头用--加一行注释说明用途，三个月后回看不用猜。子流程封装：连接数据库和关闭数据库封装成"打开连接""安全关闭"两个子流程，所有数据库应用复用。

易错速查：归档最容易翻车的6个点

1. DELETE的WHERE和INSERT的WHERE条件不一致——先核对行数再删，永远如此
2. 备份表没建就跑INSERT SELECT——报"表不存在"，先CREATE TABLE LIKE
3. 一口气迁移百万行导致锁表——用LIMIT分批，批间加等待
4. 归档期间采集流程还在写入——把归档计划任务排在采集空闲时段
5. 时区问题导致日期条件偏移——确认数据库时区和影刀RPA取的时间一致
6. 忘记【关闭数据库】——连接挂着占资源，Finally块必放关闭指令

学习资源

完整归档流程源码我放在代码仓库 home.linyan.cloud，可以直接参考改造，包括分批归档的主流程和行数核对的子流程。SQL部分想再深入的，MySQL官方文档里INSERT和DELETE两章讲得最权威，遇到语法问题优先查它。

#影刀RPA #RPA自动化 #MySQL #定时任务 #数据归档

作者：林焱