测试环境菜单误删排查与恢复

需求背景

测试环境的菜单被误删，需要排查是否存在备份，找回菜单及必要的关联数据，并在核对后还原。

目前尚未确认数据库实例、库表、误删时间、菜单范围及备份情况。以下为排查方案，不代表已经找到备份或执行恢复。

1. 先确定误删范围

向操作人确认并记录：

测试环境对应的数据库实例和库名。
菜单表、角色菜单关联表，以及其他实际涉及的关联表。
大概误删时间、操作入口、菜单名称或 ID。
是否包含子菜单、按钮权限，是否同时删除了角色授权关系。
是物理删除，还是通过删除标记实现的逻辑删除。

先只读查看表结构和现有数据。若为逻辑删除，优先核查删除标记及关联数据状态；不要直接套用物理删除恢复流程。

其他环境没有对应数据时，优先查本环境的备份、快照、日志归档和 binlog。其他环境即使存在相似菜单，也要核对版本、ID 和权限关系，不能直接复制。

2. 优先排查备份

向 DBA 或环境维护人员确认：

是否有删除前的全量备份、快照或逻辑导出文件。
是否支持按时间点恢复，保留时间是否覆盖误删时间。
是否有 binlog 归档，以及对应实例和时间段。

有备份时，先恢复到独立临时库或临时实例，再提取目标菜单及关联数据。不要直接用旧备份覆盖整个测试库，以免覆盖误删之后的其他有效变更。

只有较早备份时，可评估结合连续 binlog，将临时实例恢复到误删操作之前。具体恢复方式取决于备份类型和数据库平台能力。

3. 查询 binlog 配置和文件

以下 SQL 均为只读查询，可在目标测试实例执行：

SELECT VERSION(), @@hostname, @@port, DATABASE();
 
SHOW VARIABLES WHERE Variable_name IN (
  'log_bin',
  'binlog_format',
  'binlog_row_image',
  'log_bin_basename',
  'binlog_expire_logs_seconds',
  'expire_logs_days'
);
 
SHOW BINARY LOGS;

部分变量随 MySQL 版本不同而不存在，查询结果中没有对应项不代表查询失败。

配置	排查含义
`log_bin`	当前是否开启 binlog，还需确认误删时是否开启
`binlog_format`	`ROW` 可记录行变更；`STATEMENT` 通常记录执行语句；`MIXED` 需要查看实际事件
`binlog_row_image`	行模式下，`FULL` 通常记录完整删除前镜像；`MINIMAL` 可能仅有定位字段，无法仅靠该事件还原整行
`log_bin_basename`	当前日志文件的基础路径，读取通常需要服务器文件权限
日志过期配置	用于了解保留策略，实际可用范围以现存文件和归档为准

当前配置不能证明误删时的配置。日志存在也不保证一定包含目标操作，还需要核对实例、时间、记录内容和是否存在日志过滤等情况。

参考：MySQL 二进制日志配置。

4. 解析误删时间段

以下为终端命令，不是在 SQL 窗口执行。由有权限的人员使用与服务器版本兼容的 mysqlbinlog 工具，将路径和时间替换为实际值：

mysqlbinlog \
  --base64-output=DECODE-ROWS \
  -vv \
  --start-datetime="2026-10-28 09:00:00" \
  --stop-datetime="2026-10-28 12:00:00" \
  /var/lib/mysql/binlog.000123 > /tmp/menu_binlog_check.txt

上面的时间仅为示例。时间参数按运行工具的机器本地时区解释，需要与误删时间统一。若时间段跨多个文件，应按顺序解析全部相关文件，避免遗漏事务或表映射事件。

在结果中搜索实际库名、表名和菜单 ID，检查附近的事务边界、事件时间及删除内容。行模式示例：

### DELETE FROM `example_db`.`menu`
### WHERE
###   @1=12345
###   @2='示例菜单'
###   @3=100

这里是删除前行数据的伪 SQL 展示，并非一定等于原始执行 SQL。@1、@2、@3 是字段序号，需要结合删除时的表结构解释，不能只按当前表结构盲目转换。

注意同时排查菜单表和授权关联表。行模式日志通常不能直接确定业务操作人；需要追查“谁删的”时，还要结合已留存的数据库审计日志或应用操作日志。

参考：mysqlbinlog 使用说明、行事件展示说明。

5. 准备恢复数据

从临时恢复库或完整的删除前行镜像中提取数据后，先只读核对：

原菜单 ID 是否已被重新使用，是否已经有人手工补建。
父菜单是否存在，子菜单与按钮权限是否完整。
路由、组件、权限编码、排序、启用状态及所属系统或租户是否正确。
角色菜单关联是否也被删除；只恢复菜单不一定能让原用户重新看到菜单。
当前表结构、字段约束与备份时是否一致。

保留原 ID 通常有助于恢复关联关系，但必须先排除主键冲突和业务冲突。恢复 SQL 应明确列出字段和目标数据，不直接回放整段 binlog，也不批量恢复同一事务内与菜单无关的变更。

如果只有 MINIMAL 删除事件中的主键，需要继续寻找备份或其他可信历史数据，不能据此推断缺失字段。

6. 执行前确认与恢复后验证

所有数据库写入都需要先展示以下内容，并等待用户明确回复 “确认执行”：

目标环境、实例、数据库和表。
完整 SQL 或操作内容，包括实际使用的事务控制语句。
预计新增或修改的行数，以及菜单和关联记录范围。
冲突核查结果、备份方式和回退方案。

对于支持事务的表，优先使用事务并核对影响行数；事务执行及提交仍需在上述确认范围内。备份若需要建表或写入数据，也必须先获得确认。

恢复后验证数据库记录、菜单父子关系、前端菜单展示、路由访问和对应角色权限。若系统有菜单缓存，按实际机制刷新并验证。

7. 没有备份或 binlog 时

继续排查云平台日志归档、历史导出、初始化脚本、代码中的菜单配置、应用审计日志等来源。审计日志可能只有操作语句或 ID，不一定包含完整删除前数据。

若仍没有完整数据，只能根据需求重建菜单及授权关系，并明确这是重建，无法保证与误删前完全一致。现在开启 binlog 不能补回历史记录。

当前待补充信息

测试数据库实例与库名。
菜单及关联表名。
误删时间段、菜单名称或 ID。
备份、快照、binlog 的可用范围。
是否有人已经手工补建或修改相关数据。

Afyke的个人博客

探索

02.测试环境菜单误删排查与恢复