简介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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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 enamedan_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 enamebaidd WHERE id2; -- 会话B在另一个连接里执行相同行的更新 UPDATE baidd.t2 SET enamedan WHERE id2;会话 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 h127.0.0.1,P3306,Dbaidd,tflow_log,uarchiver,pxxx \ --dest h192.168.1.10,P3306,Dbaidd_hist,tflow_log,uarchiver,pxxx \ --where create_time DATE_SUB(NOW(), INTERVAL 3 MONTH) \ --limit 1000 --commit-each --purge参数作用建议值--source源表连接信息线上库--dest归档目标表历史库--where归档条件按日期滚动--limit每批处理行数1000--commit-each每批单独提交固定开启--purge归档后从源表删除视保留策略--purge是真正删除源表数据的开关归档演练阶段可以先不开确认数据完整再启用。我一般把归档任务放在凌晨盯一周执行日志确认慢查询数量没有异常再放手。4.2 Binlog2SQL从 binlog 里翻出你要的那段变更Binlog2SQL 是排查误操作和生成回滚 SQL 的利器。Archery 把它可视化后不需要记一堆命令行参数。比如我想看 master-bin.000009 从 857 到 1183 位置之间执行了什么 SQL在界面上填好实例、binlog 文件名、起止位置点获取 SQLArchery 异步解析并返回结果完成后有通知。如果目标是生成回滚 SQL先点flashback开关再点获取 SQL。输出就不再是原始 SQL而是逆向语句INSERT 变 DELETEDELETE 变 INSERTUPDATE 变反向 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 只能回滚 DMLDDL 在 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:pass127.0.0.1:3306/baidd \ --target mysql://sync_user:pass192.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 使用手册》里还有每一步操作的界面截图和按钮位置对照工单页面走一遍会更顺手需要的话直接下载完整版。希望这些细节能帮你在搭审核流程时少走几步弯路。本文还有配套的精品资源点击获取