为什么需要删除接口迁移演示前经常需要重复操作删除旧演示数据 重新跑主档 重新跑实时/冻结/告警 重新跑 WalkBy 重新验证页面如果每次都手写 SQL风险很高。因此需要接口化删除。两类删除能力删除接口最开始只删除迁移数据。后来需求变成删除该客户下所有业务数据这两个语义不同。只删除迁移数据依据迁移范围表删除mig_meter_scope只清理由迁移产生的数据。删除客户全部业务数据依据组织、资产绑定、部门范围删除。包括后续 CDC 同步过来的数据新系统里手动新增的数据迁移产生的数据这个能力更适合演示环境和测试环境生产上要非常谨慎。为什么路径语义要清楚接口路径应该明确表达含义。例如DELETE /migration/business表示删除客户全部业务数据。如果还要保留只删迁移数据的能力可以单独提供DELETE /migration/business/migration-data避免调用方误用。删除顺序删除顺序很关键。一般要先删子表再删主表告警列表 告警主表 冻结数据 实时消息 WalkBy 关系表 WalkBy 记录表 WalkBy 任务/册子/计划 设备扩展 资产绑定 设备主档 迁移范围表否则容易遇到外键约束、关系残留或页面脏数据。MySQL 的删除限制MySQL 有一个常见报错You cant specify target table for update in FROM clause意思是不能在删除某张表时又在子查询里直接引用同一张表。解决办法是deletefromtarget_tablewhereidin(selectidfrom(selectidfromtarget_tablewhere...)tmp);或者先把范围拆到独立查询里避免同表直接嵌套。删除接口为什么会慢全量删除慢通常有几个原因业务范围定位 SQL 太复杂大表缺索引or条件导致索引失效多层in (select ...)关系表数据多删除时锁等待优化方向是先缩小设备范围 再按设备范围删除业务表 每一步打日志 避免重复计算同一批范围删除日志必须打删除接口不能只返回最终结果。至少要记录开始删除哪个客户 删除实时数据多少 删除冻结数据多少 删除告警数据多少 删除 WalkBy 数据多少 删除主档多少 删除完成否则接口跑几分钟时调用方完全不知道是在执行、卡住还是锁等待。生产环境的原则删除接口要非常保守。建议默认只允许明确业务账号 不支持空参数全删 删除前 dry-run 或返回范围统计 测试环境可开放更多能力 生产环境需要权限控制迁移接口写错还能补删除接口删错往往很难恢复。总结删除接口不是迁移工具的附属品而是高风险能力。设计时要明确删什么 按什么范围删 按什么顺序删 删了多少 是否允许生产调用只有这样演示和测试才能高效生产数据也不会被误伤。