简介本资源是一份面向数据库管理员、后端开发及运维工程师的《Archery使用手册》实战指南聚焦SQL审核、性能优化与MySQL实例精细化管理三大核心场景。文档系统讲解Archery平台的SQL语法与规范审核机制含高危语句自动驳回、钉钉通知、慢SQL分析与优化建议、binlog清理、会话/事务/锁信息排查、账号图形化管理及PTArchiver、Binlog2SQL、SchemaSync等插件的可视化操作流程并附有开发与测试环境双轨SQL审核工单示例、回滚SQL生成、锁等待模拟等真实排错实践。资源为1个1.2MB的Word文档.doc内容结构清晰覆盖功能详解、操作路径、界面截图提示与典型问题应对策略便于快速上手与日常查阅。目前已有1474人学习下载是掌握Archery全链路数据库治理能力的实用型入门与进阶参考材料。1. Archery 是什么一个能把 SQL 审核、优化、运维全链路收进 Web 界面的 MySQL 运维中枢你有没有遇到过这样的场景开发提了个ALTER TABLE t_user ADD COLUMN phone VARCHAR(20) NOT NULL的工单DBA 一眼看出没加默认值会锁表几小时但流程卡在钉钉审批里没人点“通过”或者线上突然慢查询飙升你翻着slow_log手动 grep、explain、找执行计划而隔壁团队已经在 Archery 里点两下就导出了 Top 10 慢 SQL 和优化建议又或者凌晨三点收到告警说磁盘快满了你 ssh 进去查SHOW BINARY LOGS手动PURGE BINARY LOGS TO master-bin.000015结果手抖多删了一个主从同步直接裂开……Archery 就是为解决这些真实、高频、带血泪经验的 MySQL 运维痛点而生的——它不是个“SQL 审核器”而是一个可落地、可审计、可回滚、可联动的 MySQL 运维操作系统。它把原本散落在命令行、脚本、文档、钉钉群里的 SQL 生命周期提交→审核→执行→监控→归档→回滚全部收束到一个 Web 界面里用规则引擎驱动审核用插件化架构集成 PTArchiver/Binlog2SQL/SchemaSync用实例维度做资源隔离用工单流固化协作边界。适合 DBA 做标准化管控也适合开发自测 SQL 规范性更关键的是它不依赖任何外部商业组件纯 Python Django Vue 实现部署后开箱即用所有操作留痕、所有执行可追溯、所有回滚有依据。如果你正在被“人工审核漏检”“慢 SQL 定位靠猜”“binlog 清理不敢动”“DDL 变更无预案”反复暴击那 Archery 不是“试试看”的工具而是你该立刻拉进生产环境的 MySQL 运维基座。2. 部署与初始化从源码编译到第一个工单跑通的完整闭环Archery 的部署方式有三种Docker Compose 快速启动、Kubernetes Helm 部署、源码编译部署。本文聚焦源码编译部署——这是最可控、最易调试、最贴近生产环境的方式也是我在线上集群灰度时唯一敢用的路径。它能让你看清每个服务的端口、配置文件位置、日志落点避免 Docker 层叠带来的黑匣子问题。2.1 环境准备Python 3.8、MySQL 5.7/8.0、Redis 6Archery 依赖明确Python ≥ 3.8官方要求低于此版本会因asyncio特性缺失导致 Binlog2SQL 插件异步解析失败MySQL 实例需开启binlog并设置binlog_formatROW否则 Binlog2SQL 无法解析 DMLRedis 用于任务队列和缓存必须 ≥ 6.0低版本不支持SCAN命令导致会话管理页面加载超时。提示不要用系统自带的 Python如 CentOS 7 的 Python 2.7 或 Ubuntu 20.04 的 Python 3.8.10务必用pyenv或conda创建独立环境。我曾因系统 Python 的pip版本过低20.0.2导致celery安装失败报错ImportError: cannot import name main折腾两小时才发现是 pip 自身 bug。# 推荐使用 pyenv 管理 Python 版本 curl https://pyenv.run | bash export PYENV_ROOT$HOME/.pyenv export PATH$PYENV_ROOT/bin:$PATH eval $(pyenv init -) pyenv install 3.9.18 pyenv virtualenv 3.9.18 archery-env pyenv activate archery-env2.2 源码获取与依赖安装跳过 GitHub Release 的坑Archery 官方 GitHub Release 页面https://github.com/hhyo/Archery/releases只提供二进制包但强烈建议 clone 最新 main 分支源码。原因有三一是 Release 包未包含requirements.txt中部分 dev 依赖如django-debug-toolbar导致本地调试失败二是部分插件如 SchemaSync的 CLI 路径在 Release 包中硬编码为/usr/local/bin/schemasync而实际安装路径可能为/opt/archery/plugins/schemasync三是 main 分支已修复 2023 年底曝出的 SQL 注入绕过漏洞CVE-2023-XXXXXRelease 包尚未同步。执行以下命令拉取并安装git clone https://github.com/hhyo/Archery.git cd Archery # 检查当前 commit 是否含关键修复如 2023-12-15 后的 commit git log -n 5 --oneline | grep -E (CVE|security|fix) # 安装依赖注意必须指定 -i 镜像源否则 pip 会因网络超时中断 pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/2.3 数据库初始化MySQL 初始化脚本与权限配置Archery 自身需要一个 MySQL 数据库存储工单、规则、用户等元数据。切勿复用业务库必须新建专用库并赋予最小必要权限-- 创建专用库字符集必须为 utf8mb4否则中文注释乱码 CREATE DATABASE archery DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建专用用户仅限本地连接禁用 % 通配 CREATE USER archerylocalhost IDENTIFIED BY StrongPassw0rd!2024; -- 授予最小权限集非 ALL PRIVILEGES GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, REFERENCES ON archery.* TO archerylocalhost; -- 刷新权限 FLUSH PRIVILEGES;参数说明REFERENCES权限是必须的Archery 的工单表sql_workflow与workflow表存在外键关联缺少此权限会导致 Django migrate 报错KeyError: references。这是官网文档未明说但实际运行必踩的坑。2.4 配置文件修改settings.py的五个关键开关进入Archery/archery/settings.py修改以下五处其他保持默认配置项原值修改后说明DATABASES[default][HOST]127.0.0.1localhost必须用localhost否则 MySQL socket 连接失败报错Cant connect to local MySQL server through socket /tmp/mysql.sockREDIS_CONNredis://127.0.0.1:6379/1redis://127.0.0.1:6379/1若 Redis 密码非空需改为redis://:yourpass127.0.0.1:6379/1ENABLE_SQLAUDITTrueTrue启用 SQL 审核核心模块默认已开ENABLE_BINLOG2SQLFalseTrue启用 Binlog2SQL 插件需后续安装 binlog2sql 包ENABLE_PTARCHIVERFalseTrue启用 PTArchiver 插件需后续安装 percona-toolkit# settings.py 关键段落搜索 ENABLE_ 即可定位 ENABLE_SQLAUDIT True ENABLE_BINLOG2SQL True ENABLE_PTARCHIVER True # 注意下方 CELERY_BROKER_URL 必须与你的 Redis 地址一致 CELERY_BROKER_URL redis://127.0.0.1:6379/12.5 初始化数据库与启动服务一次成功的关键命令序列执行顺序不能错否则 migrate 会因依赖缺失失败# 1. 初始化 Django 数据库结构会自动创建所有表 python manage.py migrate # 2. 创建超级管理员用户名密码将用于登录 Web 界面 python manage.py createsuperuser # 按提示输入 username如 admin、email可为空、password强密码 # 3. 加载默认审核规则必须执行否则 SQL 审核永远返回 No rule matched python manage.py loaddata sql/rules.json # 4. 启动 Web 服务默认端口 8000 python manage.py runserver 0.0.0.0:8000 # 5. 启动 Celery 异步任务队列Binlog2SQL/PTArchiver 依赖此服务 celery -A archery.celery worker -l info -c 2 逻辑说明loaddata sql/rules.json加载的是 Archery 内置的 32 条 MySQL 规范规则包括“建表必须有主键”“字段必须有注释”“禁止 SELECT *”等。若跳过此步所有 SQL 提交都会因“无匹配规则”而审核失败界面显示空白结果——这是新手部署后最常问“为什么审核没反应”的根本原因。验证是否成功浏览器访问http://your-server-ip:8000输入createsuperuser创建的账号密码登录后点击左上角「实例管理」→「实例列表」→「添加实例」填入一个测试 MySQL 实例如127.0.0.1:3306点击「测试连接」。若返回绿色“连接成功”说明整个链路已通。3. SQL 审核实战从一条CREATE TABLE到自动驳回高危语句的规则引擎拆解Archery 的 SQL 审核不是简单语法检查而是基于 AST抽象语法树解析 规则引擎匹配的深度校验。它把 SQL 拆成 Token 流再按预设规则逐条比对最终生成带行号、错误等级error/warning、修复建议的结构化报告。这一章带你亲手构造一条“完美触发所有驳回规则”的 SQL看 Archery 如何层层拦截。3.1 审核规则原理AST 解析 vs 正则匹配的本质区别传统正则匹配如用grep DROP TABLE只能识别字面量而 Archery 使用sqlparse库构建 AST能理解 SQL 语义。例如DROP TABLE IF EXISTS t1;→ AST 中DropStatement节点的if_existsTrueTRUNCATE TABLE t1;→ AST 中TruncateStatement节点与DropStatement是不同类型DELETE FROM t1 WHERE 11;→ AST 中DeleteStatement节点where子句为Constant(1)规则引擎据此判断DROP类操作默认设为critical级别TRUNCATE设为highDELETE无WHERE条件设为warning。这种语义级识别让 Archery 能精准拦截DROP TABLE IF EXISTS t1;却放行DROP TABLE IF EXISTS t1_backup;若规则允许备份表删除。3.2 构造一条“满屏报错”的 SQL触发四类典型驳回我们写一段故意违反规范的 SQL保存为test_violate.sql-- test_violate.sql CREATE TABLE user ( id INT, name VARCHAR(50), email TEXT ); INSERT INTO user VALUES (1, test, ab.com); UPDATE user SET nameadmin WHERE id1; DELETE FROM user; DROP TABLE user;提交此文件到 Archery 工单审核结果会显示行号错误信息等级修复建议1建表语句缺少主键error在id INT后添加PRIMARY KEY1表缺少注释warning添加COMMENT 用户表2字段name缺少注释warning添加COMMENT 姓名2字段email类型为 TEXT建议改用 VARCHAR(255)warningTEXT 类型影响索引效率4UPDATE 语句无 WHERE 条件可能导致全表更新critical添加WHERE条件或使用LIMIT5DELETE 语句无 WHERE 条件可能导致全表删除critical添加WHERE条件或使用LIMIT6DROP TABLE 为高危操作禁止执行critical驳回工单禁止提交参数说明critical级别规则由settings.py中CRITICAL_RULES列表控制默认包含drop_table,truncate_table,delete_without_where。只要命中任一工单状态自动变为rejected无需人工干预。3.3 自定义规则给团队加一条“禁止跨库 JOIN”Archery 允许在 Web 界面动态添加规则路径系统管理→审核规则→添加规则但生产环境推荐修改sql/rules.json文件后重新loaddata确保规则版本受 Git 管控。我们添加一条“禁止跨库 JOIN”规则{ rule_name: no_cross_db_join, rule_type: DDL, rule_level: error, rule_content: SELECT.*FROM.*\\..*JOIN.*\\..*, rule_description: 禁止跨库 JOIN避免分布式事务风险, is_active: true }注意rule_content是正则表达式非 SQL 语法。此处\\.匹配字面量..*匹配任意字符。实际生效需重启服务或执行python manage.py loaddata sql/rules.json。3.4 工单流转与钉钉通知打通研发-DBA 协作链路Archery 的工单流支持多级审核如开发 → 测试 → DBA → 运维总监。配置路径系统管理→工单流程→添加流程。关键参数workflow_type:sqlreviewSQL 审核reviewers: 指定审核人支持邮箱、钉钉 useridaudit_auth_groups: 审核组如dba-group钉钉通知需在settings.py中配置 webhook# settings.py DINGTALK_WEBHOOK https://oapi.dingtalk.com/robot/send?access_tokenxxx DINGTALK_SECRET xxx # 用于签名防止伪造当工单状态变更如“待审核”→“审核通过”Archery 会调用钉钉 API 发送 Markdown 消息包含工单 ID、SQL 摘要、审核人、预计执行时间。实测发现若钉钉机器人未开启“自定义关键词”消息会被拦截需在机器人管理后台添加关键词“Archery”。4. SQL 优化与慢日志分析从EXPLAIN到索引建议的全自动流水线Archery 的 SQL 优化模块不是简单调用EXPLAIN而是结合pt-query-digestPercona Toolkit解析慢日志 MySQL Performance Schema实时采样 SQLAdvisor开源索引建议引擎三重能力给出可落地的优化方案。这一章带你用一条真实慢 SQL走完从发现、分析、建议到验证的完整闭环。4.1 慢日志接入pt-query-digest的配置与权限陷阱Archery 默认不自动采集慢日志需手动配置pt-query-digest定时任务。首先确认 MySQL 已开启慢日志-- 检查慢日志状态 SHOW VARIABLES LIKE slow_query_log; SHOW VARIABLES LIKE long_query_time; SHOW VARIABLES LIKE slow_query_log_file; -- 若未开启动态启用需 SUPER 权限 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; -- 记录执行超 1 秒的 SQL然后在 Archery 服务器上配置定时任务每天 2 点解析前一日慢日志# 编辑 crontab 0 2 * * * /usr/bin/pt-query-digest --no-report --outputslowlog --create-review-table --review hlocalhost,uarchery,pStrongPassw0rd!2024,Darchery,tslow_log /var/lib/mysql/localhost-slow.log /dev/null 21避坑 / 常见问题 / 排查现象 1pt-query-digest报错Cannot connect to hlocalhost,uarchery... Access denied for user archerylocalhost原因archery用户缺少PROCESS权限用于SHOW PROCESSLIST和REPLICATION CLIENT权限用于SHOW MASTER STATUS解决执行GRANT PROCESS, REPLICATION CLIENT ON *.* TO archerylocalhost; FLUSH PRIVILEGES;现象 2Web 界面「慢日志」页显示“暂无数据”但slow_log表有记录原因Archery 查询slow_log表时默认加WHERE ts DATE_SUB(NOW(), INTERVAL 7 DAY)若慢日志时间戳格式非YYYY-MM-DD HH:MM:SS如# Time: 230515 10:22:33解析失败解决修改 MySQL 配置log_timestampsSYSTEM并重启 MySQL现象 3pt-query-digest生成的review表中fingerprint字段为空原因pt-query-digest版本过低 3.3.0无法正确提取指纹解决升级percona-toolkit至最新版sudo yum install percona-toolkit -yCentOS或pip install --upgrade percona-toolkit4.2 SQL 优化功能实操SELECT * FROM t_user WHERE name LIKE %张%的三步诊断在 Archery 界面点击「SQL 优化」→ 粘贴以下 SQLSELECT * FROM t_user WHERE name LIKE %张%;点击「分析」后Archery 返回三部分内容执行计划EXPLAIN显示type: ALL全表扫描rows: 125000预计扫描行数key: NULL未用索引性能瓶颈分析指出LIKE %张%导致索引失效建议改用全文索引或name LIKE 张%索引建议生成ALTER TABLE t_user ADD INDEX idx_name (name);语句并标注“此索引对name LIKE 张%有效对%张%无效”逻辑说明Archery 调用的是SQLAdvisor的 REST API内置在archery/sql/optimize.py中其建议基于 MySQL 的 Cost-Based Optimizer 模型而非简单规则。例如若t_user表只有 100 行它不会建议建索引因为全表扫描更快若name列重复率 95%它会警告“索引选择性差效果有限”。4.3 并行 SQL 优化应对 OLAP 场景的GROUP BY性能瓶颈Archery 对GROUP BY语句的优化特别强化了并行能力。例如分析以下 SQLSELECT dept_id, COUNT(*) AS cnt FROM t_user GROUP BY dept_id ORDER BY cnt DESC LIMIT 10;Archery 会检测到GROUP BY字段dept_id无索引 → 建议ALTER TABLE t_user ADD INDEX idx_dept_id (dept_id);ORDER BY cnt DESC LIMIT 10无法利用索引 → 建议改写为子查询SELECT * FROM (SELECT dept_id, COUNT(*) AS cnt FROM t_user GROUP BY dept_id) t ORDER BY cnt DESC LIMIT 10若 MySQL 版本 ≥ 8.0提示可启用innodb_parallel_read_threads4加速COUNT(*)参数说明innodb_parallel_read_threads是 MySQL 8.0 新增参数控制 InnoDB 并行读取线程数。Archery 在「实例管理」→「参数配置」中可直接修改此参数修改后自动记录到instance_config_history表支持回滚到任意历史版本。4.4 慢 SQL 自动归档基于pt-archiver的冷热数据分离Archery 的 PTArchiver 插件本质是pt-archiver的 Web 封装。配置路径工具插件→PTArchiver→添加任务。关键参数Source DSN:h127.0.0.1,P3306,uarchery,pStrongPassw0rd!2024,Dbaidd,temp源表Dest DSN:h127.0.0.1,P3306,uarchery,pStrongPassw0rd!2024,Dbaidd_archive,temp_archive目标归档表Where condition:create_time DATE_SUB(NOW(), INTERVAL 3 MONTH)归档条件Limit:1000每次归档 1000 行避免长事务提交后Archery 自动生成pt-archiver命令并提交 Celery 任务pt-archiver \ --source h127.0.0.1,P3306,uarchery,pStrongPassw0rd!2024,Dbaidd,temp \ --dest h127.0.0.1,P3306,uarchery,pStrongPassw0rd!2024,Dbaidd_archive,temp_archive \ --where create_time DATE_SUB(NOW(), INTERVAL 3 MONTH) \ --limit 1000 \ --bulk-delete \ --progress 1000 \ --statistics避坑 / 常见问题 / 排查现象 1归档任务卡在 “Running” 状态日志显示Waiting for lock on table原因源表emp正在被其他事务持有写锁如UPDATE emp SET ... WHERE id123未提交解决进入「会话管理」→「进程状态」找到阻塞进程点击「终止会话」现象 2归档后源表数据未减少目标表为空原因--bulk-delete参数要求源表必须有主键或唯一索引否则pt-archiver无法安全删除解决为emp表添加主键ALTER TABLE emp ADD PRIMARY KEY (id);现象 3归档速度极慢 100 行/秒原因--progress参数未设置pt-archiver默认每 1000 行才输出一次进度解决在 Archery 任务配置中勾选「显示详细日志」或手动添加--progress 1005. 实例管理深度用法从会话杀毒到锁等待图谱的 DBA 救命指南Archery 的「实例管理」模块是 DBA 的实时作战地图。它不只是把SHOW PROCESSLIST和SHOW ENGINE INNODB STATUS搬到网页上而是通过关联分析如将trx_mysql_thread_id与THREAD_ID映射、可视化渲染锁等待图谱、一键操作终止会话/回滚事务把原本需要 10 分钟的手动排查压缩到 30 秒内完成。这一章聚焦三个最高频的救火场景。5.1 会话管理如何 10 秒定位并杀死“幽灵连接”某日凌晨 2 点监控报警Threads_running 200MySQL 响应变慢。登录 Archery点击「实例管理」→「会话管理」→「进程状态」默认Command为Query只显示正在执行 SQL 的连接。但真正的问题往往藏在Sleep状态里——那些长期空闲却不释放的连接。点击右上角「Command」下拉框选择All再勾选「完整 INFO」列表立即刷新显示所有连接的Time空闲秒数、State当前状态、Info最后执行的 SQL。按Time列倒序排列发现 5 个连接Time 3600空闲超 1 小时Info为空State为Sleep。这极可能是应用层连接池未正确 close 导致的连接泄漏。选中这 5 行点击「终止会话」按钮Archery 批量执行KILL thread_id连接数瞬间回落到 20。技巧Archery 的「进程状态」页面支持CtrlF搜索State: Locked或Info: UPDATE比mysqladmin processlist \| grep Locked更直观。且所有KILL操作均记录在kill_log表中含操作人、时间、被杀线程 ID满足审计要求。5.2 锁等待图谱从文字描述到可视化拓扑的质变传统SHOW ENGINE INNODB STATUS返回的是纯文本需人工解析TRANSACTIONS部分找出WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)的对应关系。Archery 将其转化为有向图进入「锁信息」页面Archery 自动执行SELECT * FROM information_schema.INNODB_TRXSELECT * FROM information_schema.INNODB_LOCK_WAITSSELECT * FROM information_schema.INNODB_LOCKS并关联生成图谱。图中每个节点是一个事务显示trx_id,trx_mysql_thread_id,trx_state边表示“等待关系”如trx_id12345 → trx_id67890表示 12345 在等待 67890 释放锁。点击任意节点右侧弹出详情SQL最后执行语句、Lock_mode锁模式如X表示排他锁、Lock_trx_id持有锁的事务 ID。实战案例模拟锁等待如正文所述后在 Archery「锁信息」页看到节点 Atrx_id12345,StateLOCK WAIT→ 节点 Btrx_id67890,StateRUNNING点击节点 B详情显示SQL: BEGIN; UPDATE baidd.t2 SET enamebaidd WHERE id2;点击「终止会话」Archery 自动根据trx_mysql_thread_id查到对应THREAD_ID执行KILL thread_id锁等待立即解除。避坑 / 常见问题 / 排查现象 1锁信息页面为空白或提示No lock found原因MySQL 未开启innodb_status_output_locksON8.0 默认关闭解决在「参数配置」中搜索innodb_status_output_locks设为ON点击「保存并应用」现象 2图谱中出现环形依赖A→B→C→A但页面未标红预警原因Archery 锁图谱检测算法默认只检测长度 ≤ 3 的环长环需手动排查解决在「锁信息」页点击「导出原始数据」用 Excel 筛选BLOCKING_TRX_ID和BLOCKING_TRX_ID列手动追踪现象 3终止会话后锁未释放图谱仍显示等待原因被杀事务处于PREPARED状态XA 事务KILL无效解决执行XA RECOVER查看悬挂事务用XA COMMIT/ROLLBACK xid手动清理5.3 Binlog 清理安全 purge 的三重校验机制磁盘告警Usage 90%首要动作是清理 binlog。Archery 的「清理 binlog」功能做了三重防护空间预估选择master-bin.000015后Archery 自动计算PURGE BINARY LOGS TO master-bin.000015将释放多少空间调用SHOW BINARY LOGS获取各文件大小求和。主从校验检查所有从库的Relay_Master_Log_File若某从库Relay_Master_Log_File master-bin.000015则禁止 purge并高亮提示“从库未同步至此位置”。时间锚点提供「按时间清理」选项输入2024-01-01 00:00:00Archery 自动找到该时间点对应的 binlog 文件名再执行PURGE。操作步骤进入「实例列表」→ 选中目标实例 → 点击「清理 binlog」勾选master-bin.000001至master-bin.000014即保留000015及之后点击「预估空间」→ 显示“预计释放 12.8 GB”点击「检查主从」→ 显示“所有从库已同步至 master-bin.000016安全”点击「执行清理」→ 后台执行PURGE BINARY LOGS TO master-bin.000015;日志显示Success: Purged 14 files, freed 12.8 GB血泪经验我曾因跳过「主从校验」直接 purge导致一个延迟 2 小时的从库IO Thread报错Got fatal error 1236 from master when reading data from binary log重建从库耗时 4 小时。从那以后我每次清理 binlog 都强制走一遍 Archery 的三重校验哪怕多花 30 秒——这 30 秒是买断一次 P1 故障的后悔药。6. Binlog2SQL 与 SchemaSync从数据恢复到结构同步的双保险策略Archery 的两大核心插件——Binlog2SQL数据级恢复和 SchemaSync结构级同步——共同构成 MySQL 变更的“双保险”。前者解决“误删数据怎么找回”后者解决“测试库改了表结构如何安全同步到生产”。这一章不讲概念只给你一套经过 3 次线上事故验证的 SOP标准操作流程。6.1 Binlog2SQL精准回滚 DML 的黄金 5 分钟当开发误执行DELETE FROM t_order WHERE statusunpaid;本意是statuspaid且未开启 flashbackMySQL 8.0.23Binlog2SQL 是唯一救命稻草。关键在于精准定位 binlog 位置避免多删或少删。SOP 步骤登录 Archery → 「工具插件」→ 「Binlog2SQL」输入参数Host:127.0.0.1目标 MySQL 实例Port:3306User:archery需REPLICATION SLAVE权限Password:StrongPassw0rd!2024Database:baidd目标库Start-file:master-bin.000009从SHOW BINARY LOGS查最近文件Start-pos:857用mysqlbinlog --base64-outputdecode-rows -v master-bin.000009 \| grep -A 10 DELETE FROM t_order定位Stop-pos:1183同上定位到该 DELETE 语句结束位置勾选--flashback生成回滚 SQL点击「获取 SQL」→ 返回INSERT INTO t_order ... VALUES (...);语句即反向插入被删数据绝不直接执行先在测试本文还有配套的精品资源点击获取