简介：SQL审核是数据库运维中控制变更风险的核心环节，其价值不仅在于语法与规范的检查，更在于将审核、执行、回滚与排查串成完整闭环。在基于语法解析的规则引擎下，平台可拦截缺少主键、高危语句等问题，并通过工单流转实现分级审批与定时执行；针对DML操作，平台基于binlog生成回滚SQL，为线上变更提供后悔药。结合会话管理、锁信息、慢日志优化及PTArchiver等工具，运维人员能更高效地处理锁等待、数据归档和结构同步场景。Archery作为开源SQL审核查询平台，正是将这些常用能力整合为一条龙流水线，适合DBA、研发与测试团队落地审核规范，保障数据库变更安全与效率。

1. Archery 是什么：SQL 审核平台里少见的"一条龙"

做数据库运维的人都有这种体会：SQL 审核本身不复杂，复杂的是审核通过之后那一串动作——谁来执行、什么时候执行、出问题怎么回滚、慢 SQL 谁来跟进。Archery 这个开源 SQL 审核查询平台最难得的地方，就是把这一串动作接成了同一条流水线。它基于语法解析做 SQL 审核，能按自定义规则检查建表主键、表注释、列注释这些规范，高危语句直接驳回；审核通过后支持立即执行或定时执行，还能生成回滚 SQL。平台右侧还接上了会话管理、锁信息、账号管理、binlog 清理，以及 PTArchiver、Binlog2SQL、SchemaSync 三个运维工具的图形化入口。这篇笔记适合正在搭 SQL 审核流程的 DBA、研发和测试同学，照着中间的步骤走，可以完整复现一遍"开发提交 → 审核 → 执行 → 回滚 → 排查"的日常闭环。

2. 跑通 SQL 审核链路：检测、提交、执行、回滚的完整闭环

2.1 审核规则如何生效

Archery 的审核不是简单的关键字匹配。它底层通过语法解析器读取 SQL，再把解析结果和一套自定义规则做比对，最后返回两类问题：一类是真正的语法错误，另一类是规范类问题。

规范类问题是最值得在团队里推广的部分。建表必须有主键、表必须有注释、列必须有注释，这些都能配置成强制规则。实际落地时常见做法是，先让开发自己把 SQL 文件写好，提交工单后点"SQL 检测"，如果返回 error，说明这版 SQL 过不了审核，得按提示改完重新提交检测。

我给团队落地时的习惯是，审核规则不只卡语法。像SELECT *这种查询语法没错，但如果团队规范要求显式列名，它一样会给你 warning。这类 warning 不阻断提交，但会跟着工单记录在案，审批人看得到。也就是说，审核结果分两个层级：error 阻断流程，warning 提示风险。高危语句自动驳回走的就是 error 这条通道。

一个典型的待审核 SQL 文件长这样：

-- 建表语句，注意主键和注释 CREATE TABLE `order_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID', `order_no` varchar(64) NOT NULL COMMENT '订单号', `user_id` bigint NOT NULL COMMENT '用户ID', `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0待支付 1已支付', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单信息表'; -- 查询语句，建议显式列出字段 SELECT id, order_no, user_id, status FROM order_info WHERE user_id = 1024;

这段建表语句把主键、表注释、列注释三件事都做齐了，审核大概率只给 warning 或直接通过。如果你把PRIMARY KEY那一行去掉再提交检测，Archery 就会把"缺少主键"作为规范类问题标出来，error 级的话工单根本提交不上去。

2.2 工单流转：开发、测试环境的两种典型路径

审核链路的核心是工单，工单流转和团队角色强相关。Archery 支持多级审核，最典型的是两种路径。

开发环境标准流程：研发工程师发起 → 项目经理审核。新建工单，填库名、SQL 文件、用途说明，然后点"SQL 检测"。检测通过后点"SQL 提交"，工单进入待审批状态。项目经理登录后点右上角的通知按钮，可以看到自己的待办事项，进去审批。最后一级审核通过后，可以选择"立即执行"或者"定时执行"。工单状态变化支持群机器人通知，审核通过、执行完成都会推消息到群里，不用一直盯页面。

测试环境流程更短：测试同事从 git 拉取开发提交的 SQL 文件，在测试环境发起工单，自己审核自己执行。这个流程能成立的前提是测试库相对安全，测试同学本身承担把关角色。

有一个细节容易被忽略：工单提交前要再确认一次目标库。Archery 工单信息里的库名是手工选的，选错库在测试环境影响不大，在生产环境就是事故。我要求团队在 SQL 文件头部写清目标库名，发起人和审批人在流程里各核对一遍。

2.3 回滚 SQL 的生成原理与边界

工单执行过后，DML 类操作会对应生成回滚 SQL。界面入口是"查看回滚 SQL"和"下载回滚 SQL"两个按钮。这个能力在运维里很重要——线上工单执行完发现数据异常，回滚 SQL 就是后悔药。

回滚 SQL 的生成不依赖应用逻辑，而是基于 binlog 记录。执行工单时平台记录变更内容，按反向方式生成 undo 语句。这也是为什么 DDL 无法回滚：binlog 里没有旧表结构信息，自然生成不了反向 DDL。

注意：DDL 工单没有回滚 SQL 是机制决定的，不是平台故障。执行前先导出一份变更前的表结构作为兜底。

定时执行是生产环境最常用的选项。团队约定凌晨低峰窗口执行 DDL 类工单，Archery 到点自动跑，执行结果记录在工单详情里。执行失败也不要慌，先看错误信息，多数是锁等待超时或目标表数据量过大导致 DDL 耗时太长。

2.4 SQL 优化与慢日志：先看建议再动手

Archery 的"SQL 优化"功能针对指定 SQL 做分析并给建议。常见做法是把一条慢查询贴进去，点分析，平台返回执行计划和优化提示。比如SELECT * FROM baidd.emp WHERE ename='dan_1'，优化建议大概率指向"避免 SELECT *、为 ename 加索引"。改成显式字段后重新分析，结果会变成 OK。

慢日志模块展示慢 SQL 及统计信息，适合周期性巡检。我一般每周看一次 top 慢语句，确认没有新冒出来的全表扫描。优化建议要人工判断再落地，不是每条都要照做。

3. 实例管理实操：会话、锁、账号与 binlog 清理

3.1 会话管理：抓阻塞 SQL 的基本功

实例管理功能默认只有管理员账号能看到，这一点先记住，否则研发同学登录后发现没有入口，会以为平台坏了。

会话管理最常用的场景是排查"数据库怎么突然卡了"。点进会话管理，右上角选择实例和 command 类型，默认只显示 query，想看到全部进程就选 All。有个很实际的坑：列表默认不勾选"完整 INFO"，导致只能看到 SQL 前半截，很多慢查询诊断信息被截断。我每次排查都先勾选"完整 INFO"，再按状态排序。

定位到阻塞源之后，选中那条会话，点"终止会话"按钮即可。操作前先确认一下这是应用连接池的请求还是手工任务，终止后应用端会自动重连或报错，这一点要提前跟业务方打招呼。

3.2 事务和锁信息：模拟一次锁等待再排查

Archery 的事务信息页展示实例上的运行中事务，关键字段是trx_mysql_thread_id，它对应会话管理里的 THREAD ID。排查长事务时，最常见的路径是：在事务信息里拿到trx_mysql_thread_id，复制到会话管理里搜索，找到对应进程再终止。

锁信息是另一个高频页面。我在这里实际模拟过锁等待，两个数据库连接同时操作同一行数据：

-- 会话A：开启事务并更新 BEGIN; UPDATE baidd.t2 SET ename='baidd' WHERE id=2; -- 会话B：在另一个连接里执行相同行的更新 UPDATE baidd.t2 SET ename='dan' WHERE id=2;

会话 B 会被阻塞。此时去锁信息页面，能看到等待事务的 SQL，也就是被阻塞那条 update，同时能看到阻塞方的线程 ID。确认阻塞方后切到会话管理，搜线程 ID，终止它，会话 B 就立即恢复执行。

这个排查链路比命令行里手工查information_schema舒服很多。但要注意，Archery 的锁信息是实时快照，长时间阻塞需要用会话管理配合反复确认。

3.3 账号管理与参数配置

账号管理解决的是"开发要建账号但 DBA 不想给命令行权限"的问题。通过 Archery 的图形界面可以创建、删除数据库账号，也可以授权。授权的最小粒度一般到库级别，比如给应用账号赋予某个库的增删改查和修改表结构权限。

这里有一个实际经验：账号授权尽量遵循最小权限原则，只授业务需要的库和操作类型。Archery 界面里权限选择看着简单，但误授了 drop 或 grant 权限，风险会长期潜伏在账号体系里。

参数配置页面可以修改实例动态参数，并且会记录修改历史。这意味着每次改参数都有迹可查。我曾在另一个平台直接改参数没留痕，事后排查性能问题完全对不上时间线。用 Archery 之后，参数变更历史就成了排查依据。

3.4 清理 binlog 的删除范围

磁盘空间不足是 MySQL 运维的常见警报。Archery 的实例列表里直接提供清理 binlog 功能，操作逻辑是：选中某个 binlog 文件，该 binlog 之前的所有 binlog 都会被删除。

这个"之前的所有"是重点。清理前务必确认两点：一是目标实例没有在做主从复制，或者从库已经消费完这些 binlog；二是没有正在进行的备份任务依赖旧 binlog。删除操作不可逆，误删了从库还没同步的 binlog，从库就只能重建。

提示：清理 binlog 前先确认主从延迟为 0，并确认没有备份任务依赖旧日志。

4. 三个内置运维工具：PTArchiver、Binlog2SQL 与 SchemaSync 的落地姿势

4.1 PTArchiver：归档超过三个月的历史数据

Archery 把 pt-archiver 做成两种使用方式，一种由管理员直接添加配置，另一种由用户发起归档申请。归档最典型的场景是线上流水表：业务只需要最近三个月的流水，三个月前的数据转储到历史库。pt-archiver 按主键分批取出数据，边取边删，不会一次性锁大范围数据，对线上影响远小于全表 DELETE。

在 Archery 里配置归档任务，底层对应的命令行大致是：

pt-archiver \ --source h=127.0.0.1,P=3306,D=baidd,t=flow_log,u=archiver,p=xxx \ --dest h=192.168.1.10,P=3306,D=baidd_hist,t=flow_log,u=archiver,p=xxx \ --where "create_time < DATE_SUB(NOW(), INTERVAL 3 MONTH)" \ --limit 1000 --commit-each --purge

--purge是真正删除源表数据的开关，归档演练阶段可以先不开，确认数据完整再启用。我一般把归档任务放在凌晨，盯一周执行日志，确认慢查询数量没有异常再放手。

4.2 Binlog2SQL：从 binlog 里翻出你要的那段变更

Binlog2SQL 是排查误操作和生成回滚 SQL 的利器。Archery 把它可视化后，不需要记一堆命令行参数。比如我想看 master-bin.000009 从 857 到 1183 位置之间执行了什么 SQL，在界面上填好实例、binlog 文件名、起止位置，点"获取 SQL"，Archery 异步解析并返回结果，完成后有通知。

如果目标是生成回滚 SQL，先点"flashback"开关，再点"获取 SQL"。输出就不再是原始 SQL，而是逆向语句：INSERT 变 DELETE，DELETE 变 INSERT，UPDATE 变反向 UPDATE。

命令行等价操作：

python binlog2sql.py \ -h 127.0.0.1 -P 3306 -u binlog2sql -p 'xxx' \ -d baidd --start-file 'master-bin.000009' \ --start-position 857 --stop-position 1183 # 生成回滚SQL python binlog2sql.py \ -h 127.0.0.1 -P 3306 -u binlog2sql -p 'xxx' \ -d baidd --start-file 'master-bin.000009' \ --start-position 857 --stop-position 1183 --flashback

解析 binlog 需要账号有 SELECT、REPLICATION SLAVE、REPLICATION CLIENT 权限，别拿业务账号顶替。binlog2sql 只能回滚 DML，DDL 在 binlog 里没有旧结构信息，无法回滚。

4.3 SchemaSync：只比对表结构，别指望它管数据

SchemaSync 解决的是"两个库表结构不一致怎么办"。它读取源库和目标库的 schema，互相比较后生成同步 SQL 和对应的回滚 SQL。注意它只比对表结构，不比对数据，也不会搬数据。

典型场景：251 实例的 baidd 库下有 order_info、user_info 等多张表，249 实例的 baidd 库只有 t2 一张表。用 SchemaSync 比对后，会生成 249 相对 251 应该执行的 DDL，比如补建缺失的表、补齐字段和索引，同时生成对应的回滚 DDL。

命令行大致长这样，具体参数以手里的版本为准：

schemasync --source mysql://sync_user:pass@127.0.0.1:3306/baidd \ --target mysql://sync_user:pass@192.168.1.10:3306/baidd \ --output /tmp/schemasync_result

我的习惯是永远先读一遍回滚语句再执行正向 DDL，确认大多数字段级操作能撤销，才允许在目标库上执行。

5. 避坑与常见问题：审核工单里最容易翻车的五个细节

5.1 SQL 检测报 error 但不给具体位置

现象：提交工单点"SQL 检测"，返回 error，但提示文本很短，看不出是哪一行 SQL 出了问题。

原因：审核结果按语句逐条返回，但界面上有时没有把出错的那条和错误信息完全对应起来，特别是一份文件里包含多条语句时。

解决：把 SQL 文件拆成一条语句一个文件，或者在工单详情里展开每条语句的检测结果，定位到具体语句再改。不要拿着整份文件反复盲试。

5.2 清理 binlog 把从库还没同步的文件删了

现象：清理完 binlog 后，从库 IO 线程报错，主从同步中断。

原因：实例列表里的清理操作按"选中文件之前全部删除"逻辑执行，如果从库消费落后于选中的 binlog，就会导致从库缺文件。

解决：清理前先确认主从同步延迟为 0，最好在低峰期操作。建议在 Archery 里只对明确不做复制的实例开放清理权限。

5.3 工单执行完发现 DDL 没有回滚 SQL

现象：一个加字段的工单执行成功后，点"查看回滚 SQL"是空的。

原因：DDL 变更的旧结构信息不在 binlog 里，平台生成不了逆向语句，这是硬边界。

解决：DDL 工单执行前做好两手准备：变更前的表结构导出保留，尽量安排在低峰期执行，配合备份恢复作为兜底。不要执行完 DDL 再去找回滚方法。

5.4 锁信息里看不到完整的阻塞链

现象：锁信息页面能查到等待事务，但分不清谁阻塞了谁，或者只能看到最外层等待。

原因：锁信息是某一时刻的快照，多条会话的等待关系可能同时交错，页面展示的关联不够直观。

解决：结合事务信息和会话管理一起看。先用事务信息拿到trx_mysql_thread_id，再去会话管理里逐个确认状态和 SQL 内容，必要时看sys.innodb_lock_waits视图补全等待链。

5.5 账号创建成功但应用连不上

现象：在 Archery 账号管理里创建了账号并授权，应用却报访问拒绝。

原因：账号来源主机限制。创建账号时没注意 host 匹配规则，应用服务器 IP 不在允许列表里，权限自然不生效。

解决：创建账号时把 host 一并按应用服务器网段配置，比如'192.168.1.%'。授权后再从应用服务器实际测一次连接，不要只在本机测。

6. 进阶用法：把 Archery 审核规范接进团队日常流程

6.1 规则集按团队红线调整

审核平台的价值上限，取决于规则集和流程设计。默认规则能覆盖主键、注释、高危语句这些基础项，但每个团队都有自己的红线。比如有的团队禁止 UPDATE 不带 WHERE，有的要求 DDL 必须走定时执行窗口。这些都可以在 Archery 的规则配置里改。改成团队自己的红线之后，工单审核才有意义。

规则调整要谨慎。刚把审核平台接入团队时，我曾经把规则集设得太松，觉得先让大家用起来再说。结果三个月内出现两起线上问题：一起是没主键的表被创建了，另一起是不带 WHERE 的 DELETE 直接执行。后来把这两条规则改成 error 级拦截，再没翻过车。

6.2 流程设计与固定巡检

流程设计上，我用下来最顺的姿势是：开发在 git 提交 SQL 变更文件，测试从 git 拉取后直接发起 Archery 工单，审核通过自动在测试环境执行；生产环境另设项目经理审批环节，生产 DDL 全部默认定时执行，落在凌晨窗口。这样开发、测试、生产三段既有区分，又共用同一个审核规则集，不会出现测试环境能过、生产环境被拦下重改的窘境。

慢 SQL 和归档任务要周期性处理。Archery 的慢 SQL 模块会汇总统计信息，我每月初看一次 top 慢语句，把高频问题逐条优化掉。PTArchiver 归档任务每周检查一次执行日志，确认归档没有拖慢主库。这已经成了固定巡检项。

从那以后，我每次上线新规则都会先在测试环境跑一周真实工单，确认误报率足够低再全量生效。完整的《Archery 使用手册》里还有每一步操作的界面截图和按钮位置，对照工单页面走一遍会更顺手，需要的话直接下载完整版。希望这些细节能帮你在搭审核流程时少走几步弯路。

本文还有配套的精品资源，点击获取