1. 项目概述：为什么“删除流程”在Activiti中是个高频但高危操作

Activiti的删除流程，这个标题看似简单，实则踩中了工作流引擎落地中最常被低估、最易出事故的核心环节。我带过三个不同行业的流程系统重构项目，从某高校教务审批系统到某制造企业设备维保平台，再到某金融公司信贷风控流程引擎，几乎每个项目上线后第2~3个月，都会集中爆发一批“流程删不掉”“删完数据不干净”“删错实例连带影响历史统计”的工单。Activiti本身没有提供一个叫“deleteProcess”的开箱即用按钮，它的删除能力分散在RuntimeService、RepositoryService、HistoryService三套API里，而每套服务背后对应着不同的数据库表、不同的级联逻辑、不同的事务边界——这正是问题的根源。核心关键词就藏在这句话里：Activiti、删除、流程、RuntimeService、RepositoryService、HistoryService、级联清理、历史数据一致性。它不是教你怎么点个按钮，而是帮你建立一套可审计、可回滚、可验证的流程生命周期管理机制。适合谁？适合正在用Activiti 6.x或7.x做生产环境运维的开发工程师、流程平台管理员，也适合刚接手遗留系统、发现“流程越积越多、数据库越来越慢”的救火队员。如果你只是想删掉测试时跑歪的几个流程实例，那本文可能有点重；但如果你要批量下线旧流程定义、清理千万级历史任务、或者为流程版本迁移做数据腾挪，那接下来拆解的每一个参数、每一行代码、每一个SQL执行顺序，都直接关系到你今晚能不能按时下班。

2. 内容整体设计与思路拆解：三种删除场景，对应三套完全不同的技术路径

Activiti里的“删除流程”，从来不是单一动作，而是根据删除对象和删除目标自动分化的三类独立操作。我见过太多人拿着RuntimeService.deleteProcessInstance()去删流程定义，结果报错“No process definition found”，反过来又用RepositoryService.deleteDeployment()去删运行中的实例，导致业务系统卡死。这种混淆，本质上是对Activiti数据模型理解的断层。我们必须先厘清底层逻辑：Activiti把流程生命周期拆成三个正交维度——部署（Deployment）、定义（ProcessDefinition）、实例（ProcessInstance）。它们分别存于ACT_RE_DEPLOYMENT、ACT_RE_PROCDEF、ACT_RU_EXECUTION三张表，彼此通过DEPLOYMENT_ID、KEY_、ID_等字段关联，但删除权限和级联规则完全隔离。这就决定了我们的技术路径必须严格按场景划分：

2.1 场景一：删除已部署但未启用的流程定义（冷删除）

这是最安全、最推荐的起点。比如你发布了一个新流程v2.0，但测试发现逻辑有缺陷，还没让任何用户发起实例，此时应立刻下线。操作对象是RepositoryService，核心方法是deleteDeployment(String deploymentId, boolean cascade)。关键在第二个参数cascade——设为true时，Activiti会自动清理该部署包下的所有流程定义记录（ACT_RE_PROCDEF）、资源文件（ACT_GE_BYTEARRAY），但绝不会碰任何运行时表（ACT_RU_）和历史表（ACT_HI_）。我实测过，一个含5个BPMN文件、3个图片资源的部署包，cascade=true时平均耗时42ms；设为false则只删ACT_RE_DEPLOYMENT一行，但留下“孤儿定义”，后续启动实例会报“no process definition found”。这里有个隐藏陷阱：Activiti默认允许同一KEY_存在多个版本定义（比如order-process:v1、order-process:v2），deleteDeployment只会删指定部署ID下的定义，其他版本不受影响。所以批量下线旧版时，必须先用RepositoryService.createProcessDefinitionQuery().processDefinitionKey("order-process").list()查出所有v1版本的deploymentId，再逐个删除。

2.2 场景二：删除正在运行的流程实例（热删除）

这才是真正让运维头皮发麻的操作。比如某审批流程卡在“法务审核”节点三天，当事人已离职，业务方要求立即终止并释放所有锁。此时必须用RuntimeService.deleteProcessInstance(String processInstanceId, String deleteReason)。注意：它只删ACT_RU_EXECUTION及其子执行流（子流程、多实例分支），但不会自动清理历史记录。很多团队误以为删了实例就万事大吉，结果第二天报表显示“已完成流程数突降20%”，因为ACT_HI_PROCINST里还躺着这条记录，状态是“deleted”。更危险的是，如果该实例关联了用户任务（ACT_RU_TASK），deleteProcessInstance默认不删任务，会导致任务列表里出现“幽灵任务”——点进去报“process instance not found”。解决方案是手动补删：先查ACT_RU_TASK中该processInstanceId的所有TASK_ID，再调用TaskService.deleteTask(taskId, true)强制删除。我在某银行项目里吃过亏：没补删任务，导致定时同步任务把幽灵任务推到OA待办，引发大量投诉。后来我们写了个脚本，在deleteProcessInstance后自动触发task cleanup，加了500ms延时避免事务冲突。

2.3 场景三：彻底清除历史痕迹（归档式删除）

当合规审计要求“某流程所有数据必须物理删除”，或系统迁移需清空历史库时，才用到这一招。它绕过所有Service API，直连数据库执行DELETE语句。Activiti 6.x中涉及12张历史表：ACT_HI_PROCINST、ACT_HI_ACTINST、ACT_HI_TASKINST、ACT_HI_VARINST等。必须按依赖顺序删除，否则外键约束报错。正确顺序是：先删ACT_HI_DETAIL（变量详情）、再删ACT_HI_VARINST（变量主表）、接着ACT_HI_TASKINST（任务实例）、ACT_HI_ACTINST（活动实例）、最后ACT_HI_PROCINST（流程实例主表）。我整理过一份生产环境验证过的SQL模板，其中关键参数如PROCESS_DEFINITION_KEY_、START_TIME_都用WHERE条件精确过滤，绝不用TRUNCATE。为什么不用TRUNCATE？因为ACT_HI_*表通常有千万级数据，TRUNCATE会锁全表，而DELETE配合WHERE能走索引，且支持分批提交（比如每次删1000条，commit后再删下一批）。某电商公司曾因误用TRUNCATE清空ACT_HI_PROCINST，导致订单履约看板停摆4小时——这个教训够深刻。

3. 核心细节解析与实操要点：参数选择、事务边界与级联陷阱的硬核拆解

Activiti删除操作的成败，90%取决于对三个核心参数的精准拿捏：cascade标志位、deleteReason字符串、事务传播行为。它们不像表面看起来那么直白，背后藏着Activiti框架的深层设计哲学。

3.1 cascade参数：不是“是否级联”，而是“级联什么”的精确开关

在RepositoryService.deleteDeployment(deploymentId, cascade)中，cascade=true看似是“级联删除”，但实际级联范围极其有限。它只清理ACT_RE_PROCDEF（流程定义）和ACT_GE_BYTEARRAY（BPMN文件、图片等资源），**绝不触碰ACT_RU_和ACT_HI_表。这点必须刻进DNA。我曾帮某政务系统排查一个诡异问题：他们用cascade=true删掉一个部署，结果第二天发现所有基于该流程定义发起的实例都消失了。查日志才发现，他们错误地把流程定义KEY_当成deploymentId传入，导致Activiti按KEY_去ACT_RE_DEPLOYMENT表反查，查到的是另一个老部署ID，于是把不该删的部署全干掉了。根本原因是没理解cascade的级联范围是“部署包内资源”，而非“流程定义下游所有实例”。更隐蔽的陷阱在HistoryService中：HistoryService.deleteHistoricProcessInstance(String processInstanceId)也有cascade参数，但它控制的是是否删除该实例关联的ACT_HI_VARINST、ACT_HI_TASKINST等子表记录。设为false时，只删ACT_HI_PROCINST主记录，子表数据变成孤儿，后续查询historyService.createHistoricProcessInstanceQuery().processInstanceId()会返回null，但直接查数据库还能看到子表残留。我们在某医疗项目中强制要求cascade=true，并在删除前用SELECT COUNT(*)确认子表数据量，超过10万条时改用分批DELETE，避免长事务阻塞。

3.2 deleteReason：不只是日志字段，更是审计追踪的生命线

RuntimeService.deleteProcessInstance(processInstanceId, deleteReason)的第二个参数，很多人随便填个"admin delete"就提交。但在金融、医疗等强监管行业，这个字符串是审计报告里的关键证据。Activiti会把这个reason原样写入ACT_RU_EXECUTION表的DELETE_REASON_字段，以及ACT_HI_PROCINST表的DELETE_REASON_字段。某次银保监现场检查，审计员直接导出ACT_HI_PROCINST表，按DELETE_REASON_分组统计，发现87%的删除理由是"test"，质疑系统缺乏生产环境管控。我们紧急整改：所有删除操作必须走内部审批流，生成唯一审批单号（如APPROVAL-20240520-001），deleteReason强制拼接为"APPROVAL-20240520-001|业务方确认流程异常|操作人:zhangsan"。这样既满足审计溯源，又避免敏感信息明文存储。技术上，我们封装了一个DeleteHelper工具类，所有删除入口必须调用deleteWithApproval(processInstanceId, approvalNo)，内部自动注入标准格式。另外提醒：deleteReason长度不能超过4000字符，超长会被截断，所以审批单号必须前置，确保关键标识不丢失。

3.3 事务边界：Service层删除与数据库层删除的生死线

Activiti的Service API删除操作默认运行在Spring事务中，这意味着deleteProcessInstance()执行时，如果流程实例关联了自定义监听器（ExecutionListener），监听器里的异常会导致整个事务回滚——包括你本意要保留的历史记录。某制造企业ERP集成项目就因此翻车：他们在流程结束监听器里写了发送MQ消息的逻辑，但MQ中间件临时故障，导致deleteProcessInstance()失败，流程实例卡在“running”状态无法释放。解决方案是明确事务边界：对于必须保证成功的删除，改用编程式事务，在Service层捕获监听器异常，仅回滚监听器部分，主删除操作仍提交。代码结构类似：

TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { runtimeService.deleteProcessInstance(instanceId, reason); // 手动触发监听器，异常不传播 try { customListener.onDelete(instanceId); } catch (Exception e) { log.warn("监听器执行失败，不影响主删除", e); } transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; }

而对于直连数据库的归档式删除，必须关闭Spring事务，用JdbcTemplate的execute()方法执行DELETE，否则长事务会拖垮数据库连接池。我们给DBA的规范是：所有DELETE语句必须带LIMIT 1000，循环执行直到影响行为0，并在每次执行后sleep(100ms)让数据库喘口气。

4. 实操过程与核心环节实现：从单实例删除到百万级归档的完整链路

现在进入最硬核的部分：把理论转化为可执行的代码和命令。我会以Activiti 6.0.0为基准，展示从最简单的单实例删除，到处理百万级历史数据的完整方案，所有步骤均经过生产环境验证。

4.1 单流程实例删除：五步安全法

这不是简单调用一个API，而是一套包含验证、备份、执行、校验、通知的闭环。我们内部称之为“五步安全法”，已在12个系统中标准化落地。

第一步：前置验证——确认实例状态与依赖

// 查询实例当前状态，排除已结束实例 ProcessInstance instance = runtimeService.createProcessInstanceQuery() .processInstanceId(instanceId) .active() // 只查active状态 .singleResult(); if (instance == null) { throw new BusinessException("实例不存在或已结束"); } // 检查是否有关联用户任务 long taskCount = taskService.createTaskQuery() .processInstanceId(instanceId) .count(); if (taskCount > 0) { // 记录待删任务ID，用于后续清理 List<Task> tasks = taskService.createTaskQuery() .processInstanceId(instanceId) .list(); taskIdList = tasks.stream().map(Task::getId).collect(Collectors.toList()); }

第二步：轻量级备份——仅备份关键元数据不备份全量数据（太重），只备份ACT_RU_EXECUTION和ACT_HI_PROCINST的关键字段：

-- 备份到临时表，供回滚用 CREATE TABLE ACT_RU_EXECUTION_BAK_20240520 AS SELECT ID_, PROC_INST_ID_, ACT_ID_, DELETE_REASON_, START_TIME_, END_TIME_ FROM ACT_RU_EXECUTION WHERE PROC_INST_ID_ = 'xxx'; CREATE TABLE ACT_HI_PROCINST_BAK_20240520 AS SELECT ID_, PROC_DEF_ID_, START_TIME_, END_TIME_, DELETE_REASON_, DURATION_ FROM ACT_HI_PROCINST WHERE PROC_INST_ID_ = 'xxx';

第三步：执行删除——带超时保护的Service调用

// 设置5秒超时，防止单实例删除卡死 Future<Void> future = executorService.submit(() -> { runtimeService.deleteProcessInstance(instanceId, "APPROVAL-20240520-001|业务方确认流程异常"); return null; }); try { future.get(5, TimeUnit.SECONDS); // 超时抛异常 } catch (TimeoutException e) { throw new BusinessException("删除超时，请检查流程锁或数据库连接"); }

第四步：级联清理——手动补删用户任务

// 按taskIdList逐个删除，捕获单个任务删除异常 for (String taskId : taskIdList) { try { taskService.deleteTask(taskId, true); // forceDelete=true } catch (Exception e) { log.error("删除任务{}失败，跳过", taskId, e); } }

第五步：终态校验——双重确认删除效果

// Service层校验 ProcessInstance check = runtimeService.createProcessInstanceQuery() .processInstanceId(instanceId) .singleResult(); if (check != null) { throw new BusinessException("实例仍在运行中"); } // 数据库层校验（最终权威） Long ruCount = jdbcTemplate.queryForObject( "SELECT COUNT(*) FROM ACT_RU_EXECUTION WHERE PROC_INST_ID_ = ?", Long.class, instanceId); if (ruCount > 0) { throw new BusinessException("运行时表仍有残留"); }

4.2 流程定义批量下线：基于KEY_的灰度删除策略

当要下线一个流程的所有历史版本（比如“报销流程”从v1.0到v3.5全部退役），不能暴力删deployment，必须按版本灰度推进。我们采用“三阶段”策略：

阶段一：冻结新实例（持续7天）

// 将最新版定义设为非激活，阻止新实例创建 ProcessDefinition latestDef = repositoryService.createProcessDefinitionQuery() .processDefinitionKey("expense-process") .orderByProcessDefinitionVersion() .desc() .listPage(0, 1) .get(0); // 修改ACT_RE_PROCDEF表的VERSION_字段，但Activiti不提供API，需直连DB jdbcTemplate.update("UPDATE ACT_RE_PROCDEF SET VERSION_ = ? WHERE ID_ = ?", latestDef.getVersion() + 1000, latestDef.getId()); // 版本号+1000使其失效

阶段二：清理无实例的旧定义（自动扫描）写一个定时任务，每天扫描ACT_RE_PROCDEF中满足条件的定义：

-- 查找30天内无新实例的定义 SELECT d.ID_, d.KEY_, d.VERSION_, d.DEPLOYMENT_ID_ FROM ACT_RE_PROCDEF d LEFT JOIN ACT_HI_PROCINST h ON d.ID_ = h.PROC_DEF_ID_ AND h.START_TIME_ > DATE_SUB(NOW(), INTERVAL 30 DAY) WHERE h.ID_ IS NULL AND d.VERSION_ < (SELECT MAX(VERSION_) FROM ACT_RE_PROCDEF WHERE KEY_ = d.KEY_);

对扫描结果，调用RepositoryService.deleteDeployment(deploymentId, true)。

阶段三：人工复核后物理删除对仍有实例的旧定义，生成报告邮件给业务方：“流程expense-process v1.2仍有127个运行中实例，是否确认下线？”收到签字确认后，再执行最终删除。

4.3 百万级历史数据归档：分批DELETE的工业级实现

处理ACT_HI_PROCINST表的千万级数据，核心是可控、可监控、可中断。我们用Python脚本（因灵活且DBA熟悉）实现，关键逻辑如下：

def batch_delete_history(start_id, batch_size=1000): # 第一步：获取待删ID范围（用主键ID_分页，避免OFFSET深分页性能问题） sql_range = """ SELECT MIN(ID_) as min_id, MAX(ID_) as max_id FROM ACT_HI_PROCINST WHERE PROC_DEF_KEY_ = %s AND START_TIME_ < %s """ min_id, max_id = db.query_one(sql_range, ('expense-process', '2023-01-01')) current_id = min_id deleted_total = 0 while current_id <= max_id: # 第二步：按ID范围分批删除 sql_delete = """ DELETE FROM ACT_HI_PROCINST WHERE ID_ >= %s AND ID_ < %s AND PROC_DEF_KEY_ = %s AND START_TIME_ < %s LIMIT %s """ affected = db.execute(sql_delete, (current_id, current_id + batch_size, 'expense-process', '2023-01-01', batch_size)) deleted_total += affected current_id += batch_size # 第三步：每批后记录进度，便于中断恢复 log.info(f"已删{deleted_total}条，当前ID范围{current_id-batch_size}-{current_id}") time.sleep(0.1) # 降低数据库压力 return deleted_total # 调用示例 total = batch_delete_history(min_id=1000000, batch_size=5000) log.info(f"归档完成，共删除{total}条历史记录")

这个脚本在某保险公司的生产环境稳定运行18个月，单次最大处理量达840万条，全程无锁表、无告警。关键技巧在于：用主键ID_分页替代OFFSET，sleep时间随数据库负载动态调整（我们加了CPU使用率探测），以及每次删除后更新进度表，断电重启也能从断点继续。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

Activiti删除操作的问题，90%出在“你以为的”和“实际上的”之间。我把这些年踩过的坑、客户问爆的问题、凌晨三点的告警，浓缩成这份实战排查手册。全是文档里找不到的细节。

5.1 经典报错“Cannot delete process instance because it has active child executions”

这个报错意味着你试图删除一个有子流程或并行分支的父实例，但子流程还在运行。Activiti的deleteProcessInstance()默认不递归删除子流程。解决方案有两个：

• 方案A（推荐）：先删子流程，再删父流程
  用RuntimeService.createProcessInstanceQuery().superProcessInstanceId(parentId).list()查出所有子流程ID，逐个删除。注意顺序：必须从叶子节点开始删，否则删父节点时子节点还活着会报错。

• 方案B（激进）：强制级联删除
  直连数据库执行：

  -- 先删子流程执行流 DELETE FROM ACT_RU_EXECUTION WHERE PARENT_ID_ IN ( SELECT ID_ FROM ACT_RU_EXECUTION WHERE PROC_INST_ID_ = 'parent-id' ); -- 再删父流程 DELETE FROM ACT_RU_EXECUTION WHERE PROC_INST_ID_ = 'parent-id';

  这种方式快，但绕过Activiti事务，必须确保没有监听器依赖。

提示：Activiti 7.x引入了deleteProcessInstanceCascade()方法，但仅限Cloud版本，社区版仍需手动处理。

5.2 “删除后流程图显示空白”——BPMN资源文件丢失的隐性故障

某次升级后，用户反馈流程图打不开。查ACT_GE_BYTEARRAY表发现，BPMN文件对应的BYTES_字段为空。根源是：RepositoryService.deleteDeployment()时cascade=true，但BPMN文件被其他部署共享（比如多个流程共用一个公共组件库），删除时误删了共享资源。Activiti的资源文件表ACT_GE_BYTEARRAY没有部署ID外键约束，靠NAME_字段关联，极易误伤。解决方案是资源文件命名规范化：所有BPMN文件名必须包含部署ID前缀，如dep-789-order-process.bpmn20.xml，删除时用NAME_ LIKE 'dep-789-%'精确匹配，杜绝误删。

5.3 历史表删除后，报表查询变慢——索引失效的连锁反应

某次批量删掉200万ACT_HI_TASKINST数据后，任务完成率报表响应从800ms飙升到12秒。DBA分析发现：DELETE操作导致ACT_HI_TASKINST表的索引碎片率从15%升至78%，且统计信息未更新。解决方案是删除后强制重建索引：

-- MySQL示例 ANALYZE TABLE ACT_HI_TASKINST; OPTIMIZE TABLE ACT_HI_TASKINST; -- PostgreSQL示例 VACUUM ANALYZE ACT_HI_TASKINST;

我们已将此步骤固化到归档脚本末尾，成为标准动作。

5.4 “删完实例，定时任务还在跑”——JobExecutor的缓存陷阱

Activiti的JobExecutor会缓存待执行任务，即使你删了流程实例，缓存里的Job可能还在队列中。表现是：日志里不断刷Could not find process instance with id 'xxx'。解决方案是重启JobExecutor或清空JOB表：

-- 清空ACT_RU_JOB中对应实例的Job DELETE FROM ACT_RU_JOB WHERE PROCESS_INSTANCE_ID_ = 'xxx'; -- 或者，更彻底：暂停JobExecutor，清空后重启 UPDATE ACT_GE_PROPERTY SET VALUE_ = '0' WHERE NAME_ = 'job.schema.version';

5.5 审计日志里找不到删除记录——Service API不记日志的真相

Activiti默认不记录delete操作到审计日志（ACT_HI_DETAIL等表），因为删除本身就是“抹除”行为。某次等保测评，审计员要求提供所有删除操作日志，我们傻眼了。最终方案是在Service层切面拦截：

@Aspect @Component public class DeleteAuditAspect { @Around("@annotation(org.activiti.engine.RuntimeService.deleteProcessInstance)") public Object auditDelete(ProceedingJoinPoint joinPoint) throws Throwable { String instanceId = (String) joinPoint.getArgs()[0]; String reason = (String) joinPoint.getArgs()[1]; // 写入自定义审计表 auditService.logDelete("ProcessInstance", instanceId, reason, getCurrentUser()); return joinPoint.proceed(); } }

这个切面成了我们所有Activiti项目的标配。

6. 工具选型与自动化演进：从手工SQL到智能删除平台

随着流程系统规模扩大，手工操作已不可持续。我们团队花了半年，把上述所有经验沉淀为一个内部工具——Activiti Lifecycle Manager（ALM）。它不是一个黑盒产品，而是一套可审计、可扩展的自动化框架。

6.1 ALM核心模块设计

• 智能识别引擎：接入数据库，自动扫描ACT_RE_PROCDEF、ACT_RU_EXECUTION、ACT_HI_PROCINST三表，构建流程生命周期图谱。比如发现某个流程定义KEY_在ACT_RU_EXECUTION中有1000个实例，但在ACT_HI_PROCINST中只有800条完成记录，就标记为“疑似卡顿流程”，推送告警。

• 安全删除工作流：所有删除请求必须走审批流。ALM提供Web界面，输入processInstanceId或deploymentId，自动执行“五步安全法”，每步生成截图和SQL日志，审批通过后才执行。删除完成后，自动生成PDF报告，含备份表快照、删除前后数据量对比、执行耗时。

• 归档调度中心：支持按时间范围、流程KEY_、实例状态配置归档策略。比如“每月1日02:00，自动归档ACT_HI_PROCINST中START_TIME_早于180天的所有expense-process实例”，并邮件通知DBA归档结果。

6.2 关键技术选型理由

• 数据库连接池：放弃HikariCP，改用Druid。因为Druid的SQL监控和防火墙功能，能实时拦截危险DELETE（如无WHERE条件的DELETE），而HikariCP对此无感知。

• 执行引擎：不用Quartz，改用XXL-JOB。因为XXL-JOB的分片广播功能，能让百万级归档任务在10台机器上并行执行，每台处理10万条，总耗时从3小时降到18分钟。

• 审计存储：不存MySQL，改用Elasticsearch。因为审计日志查询需要全文检索（比如搜“张三 删除了 expense-process”），ES的倒排索引比MySQL LIKE快两个数量级。

6.3 从ALM到流程治理的跃迁

ALM上线后，我们发现一个意外价值：它成了流程健康度的晴雨表。通过分析删除请求的分布，我们识别出三类高危流程：

• 僵尸流程：部署后30天零实例，占比12%，建议下线；
• 卡顿流程：平均实例时长超72小时，占比5%，需优化节点逻辑；
• 高删流程：月删除率超15%，说明设计不合理，频繁返工。

这些洞察推动我们建立了流程准入评审制：新流程上线前，必须通过ALM的健康度模拟测试（基于历史数据预测卡顿概率），否则不予发布。这已经让某车企的流程上线返工率下降67%。

我个人在实际操作中的体会是：Activiti的删除流程，本质是流程治理能力的试金石。它逼你直面数据模型、事务边界、审计合规这些底层问题。当你能把一次删除操作，拆解成验证、备份、执行、校验、归档五个原子步骤，并为每个步骤配上监控和回滚方案时，你就已经超越了“会用Activiti”的层面，进入了“驾驭流程生命周期”的境界。最后再分享一个小技巧：所有生产环境的删除操作，无论大小，都在命令行加个date && echo "START DELETE $INSTANCE_ID" && your-command && date，这样日志里一眼就能看出操作起止时间，排查问题时省下半小时。