Archery SQL审核平台实战：从审核流程到回滚机制的完整指南

简介Archery 是一个面向 MySQL 数据库的 SQL 审核与查询平台核心目标在于规范上线流程、降低变更风险同时提供丰富的日常运维能力。这份 doc 版使用手册以专题形式编排依次介绍功能详解、实践案例、实例管理和工具插件四大模块内容由浅入深适合需要承担 SQL 发布审核、测试验证以及数据库维护的工程师阅读。资源整体为 1 个 doc 格式文档体积约 1.2MB已有一千四百七十六人学习下载。手册细致覆盖了 SQL 审核中的语法解析、建表主键与注释校验、高危语句自动驳回也讲解了 SQL 优化建议与慢日志统计的查看方法实例管理部分则包含清理 binlog 释放空间、终止阻塞会话、查看运行事务和锁信息以及账号授权与动态参数配置等操作。针对工具插件场景文档演示了 PTArchiver 实现历史数据归档、Binlog2SQL 从 binlog 解析生成回滚 SQL、SchemaSync 完成表结构同步的用法并配有开发环境与测试环境下的完整审核流程示例方便读者对照落地到自己的数据库运维工作中。1. Archery 是做什么的一条 SQL 从上不了线到安全落地的距离Archery 在国内数据库团队里的定位很明确SQL 审核查询平台顺带把 MySQL 运维里最琐碎的那批操作收进同一个界面。最早接触它是被同事拉去配审核规则当时团队里每天都有开发直接贴一条 SQL 到群里问能不能上DBA 手工看完语法看规范看完规范还得想回滚方案效率和体验都很差。Archery 做的事情就是把这些流程沉淀成平台SQL 提交上去先做语法解析再按自定义规则做规范审核审核通过可以立即执行或定时执行执行前还能一键生成回滚 SQL。它把 SQL 审核、SQL 优化、实例管理和工具插件串到一起适合研发、测试和 DBA 共用一套流程。这篇笔记按我实际使用的顺序把审核流程、优化、实例管理和插件逐个过一遍最后把踩过的坑列出来。2. SQL 审核流程怎么走研发、测试两条线的完整链路2.1 审核规则到底在审什么语法之外还有规范Archery 的 SQL 审核并不是简单跑一遍语法检查。它会先把 SQL 做完整语法解析解析不过的直接判 error这部分相当于把 MySQL 的解析逻辑搬到了平台上。解析通过之后再用一套自定义规则过数据库规范建表有没有主键、表有没有注释、列有没有注释一条条核对。规范这一层是 Archery 和普通 SQL 审核工具最大的区别也是团队引入它能统一口径的原因。我见过不少团队第一次接入时觉得规则太严实际上规则可以在后台调阈值和开关比如“高危语句自动驳回”这类规则默认把 DROP、TRUNCATE 这种操作卡在提交前。流程上Archery 把“检测”和“提交”拆成两个动作点 SQL 检测只出结果error 的 SQL 根本走不到审核人那里检测通过后再点 SQL 提交工单才进入审批流。下面这条语句就是典型的被规范规则拦下的案例-- 报错示例缺主键、无表注释 CREATE TABLE order_info ( id int NOT NULL, user_id int DEFAULT NULL, amount decimal(10,2) DEFAULT NULL );这段 SQL 语法完全合法直接拿到 MySQL 里也能执行成功但 Archery 会给出规范层面的 error缺少主键表没有注释。改成下面这样就能通过检测CREATE TABLE order_info ( id int NOT NULL COMMENT 主键ID, user_id int NOT NULL COMMENT 用户ID, amount decimal(10,2) DEFAULT NULL COMMENT 订单金额, PRIMARY KEY (id) ) ENGINEInnoDB COMMENT订单信息表;两段 SQL 对比就能理解 Archery 的审核逻辑第一段能跑通但不规范等表多了、数据大了再补主键、补注释成本比建表时高得多。规范审核做的就是提前发现问题。注意这里的 error 不等于 SQL 完全不能执行它代表“不符合平台规则”按提示改完再检测就行别被 error 两个字母吓住。2.2 开发环境流程研发提交、项目经理复核、定时执行开发环境的审核流程一般是研发工程师发起项目经理做最后一级审核整体链路比生产变更短但每一级该看的还是要看。实际走下来是这样一个顺序研发准备好要上线的 SQL 文件内容可以是建表、索引变更、数据修正等 DML 或 DDL在 Archery 里填写工单信息选择目标实例粘贴或上传 SQL 文件点“SQL 检测”如果检测结果有 error按提示把 SQL 改到检测通过再点“SQL 提交”工单进入审批流项目经理登录后点右上角通知按钮看到待办事项后审核最后一级审核通过后页面出现“立即执行”和“定时执行”两个按钮按需选择。这里有个细节如果工单里包含多条 SQLArchery 是逐条检测的某一条卡住会明确指出来不会用一条笼统的报错糊弄你。定时执行适合凌晨变更配合钉钉通知执行结果会推送给相关人。我一般建议 DDL 类的操作选定时执行避开业务高峰即使出问题也更容易止损。2.3 测试环境流程从 git 取 SQL 到测试自审自执行测试环境的流程更短常见做法是测试同事从 git 上取开发提交的 SQL 文件自己在 Archery 里发起审核审核通过后自己执行。没有项目经理那一环测试既当提交人也当审核人。流程走下来是测试同事从 git 拉取开发同事提交的 SQL 文件在测试环境实例上发起 SQL 审核同样先“SQL 检测”检测通过后“SQL 提交”审核通过后可选择执行方式执行完成后如果需要可以下载回滚 SQL 留档。这里要留意一个点测试环境的审核规则如果和生产一致很多开发写的 SQL 会在测试阶段就被拦下来这是好事。但如果测试环境规则放得松、生产环境规则严就会出现测试能过、生产提交不了的情况。我们团队的做法是两套环境的规则模板保持一致避免这种割裂。这个坑在后面避坑章节还会提到属于典型的环境差异问题。2.4 一个审核不通过的实例error 提示怎么改举一个实际碰到过的例子。开发提交了一条更新语句UPDATE user_info SET user_namedan_1 WHERE user_id10086;如果表结构里 user_name 字段长度只有 30而业务在别处拼接生成了超长字符串这类问题语法解析阶段看不出来需要结合表结构元数据审核。更常见的拦截点是规范类规则比如“UPDATE/DELETE 不带 WHERE”高危规则这类 SQL 会被自动驳回必须在提交前补上 WHERE 条件。所以我的习惯是提交前先在本地把 SQL 跑一遍 EXPLAIN确认影响行数可接受再走 Archery 检测。别把平台当最后的守门员它能卡住流程和规范但业务语义只有你自己清楚。提示SQL 检测出 error 时页面会给出具体原因和大致位置。先按提示修改改完重新检测不要试图用注释绕过规范规则对注释行也会解析。3. SQL 分析与优化把 SELECT * 改成字段列表之后3.1 SQL 优化功能怎么用一句慢 SQL 的分析过程Archery 的 SQL 优化功能本质是把 SQL 拿到平台上做执行计划和优化建议分析。拿手册里的例子输入下面这句-- 优化前全字段查询 SELECT * FROM baidd.emp WHERE enamedan_1; -- 优化后只取需要的字段 SELECT emp_id, ename, hire_date FROM baidd.emp WHERE enamedan_1;在“SQL 优化”里提交第一句平台返回执行计划和优化建议。把 SELECT * 改成具体字段列表后再分析结果会变成 OK。为什么平台建议这样改有三层原因第一ename 如果没有索引SELECT * 会走全表扫描数据量大时 IO 开销完全不一样第二哪怕有索引SELECT * 也无法利用覆盖索引必须回表取完整行数据第三应用端接收的字段越多网络传输和内存占用越大。这三层叠加在慢 SQL 场景里往往是性能问题的核心。优化建议页面里除了字段调整还会提示缺失的索引、可用的复合索引方向。注意Archery 给的是建议而不是强制修改最终加不加索引、改不改查询字段需要结合业务自己判断。平台的价值是把选择权和依据摆在你面前不是替你拍板。3.2 执行计划里的几个关键信号拿到执行计划后很多新手只盯着一张表看 type 列。我的习惯是优先看三个东西type、key 和 rows。这三个字段基本能把一条 SQL 的健康状况说清楚信号常见值含义typeALL全表扫描需要重点优化typeref / const走索引或常量匹配状态良好keyNULL没有用到索引这是优化的切入点rows数值很大预估扫描行数多说明筛选性差如果看到 type 为 ALL 且 rows 接近全表行数基本可以确定要加索引或改写 SQL。如果 type 是 ref 但 rows 还是很大说明索引区分度不够比如在性别字段上加索引就是这个效果这种场景下索引帮助有限得从 SQL 改写入手。执行计划是分析工具不是判决书它告诉你“当前是这样执行的”结合业务再决定怎么改。3.3 慢日志与统计信息别等用户投诉才回头看慢 SQL 功能会把实例里的慢查询收集起来按统计维度展示哪些 SQL 频繁出现、平均耗时多少都列得很清楚。我的使用习惯是每周固定看一次慢日志列表把出现次数排名靠前的 SQL 拉到 SQL 优化里过一遍。很多问题不是一次突发而是长期累积的慢 SQL 拖垮了实例。慢日志列表里有执行次数、平均耗时、最大耗时等列。我一般排序方式是先按平均耗时降序看一遍头部再按执行次数降序看一遍高频两者同时靠前的优先处理。有一种情况要特别注意某条 SQL 平均耗时不高但执行次数特别多累计消耗的 CPU 和 IO 反而比一条重 SQL 更吓人。这类 SQL 往往是循环调用里的漏网之鱼改一次 ORM 或存储过程收益比改一条大 SQL 还高。还要提醒一点慢日志收集本身有延迟窗口刚执行完的慢 SQL 不会立刻出现。如果业务正在被慢查询困扰先在会话管理里看实时进程再用慢日志做趋势分析两者配合才完整这也是下一章要展开的内容。4. 实例管理实战清理 binlog、终止会话、排查锁等待4.1 实例列表与 binlog 清理磁盘告警后的第一件事实例管理这块默认只有管理员账号有权限普通研发和测试账号是看不到的。实例列表页面能看到接入的每个 MySQL 实例如果磁盘空间告警最常见的手段是清理 binlog。操作方式进入实例列表选中某个 binlog点击清理该 binlog 之前的所有 binlog 都会被删除。这个逻辑简洁但危险误选就是批量删除。清理前一定要确认两件事第一从库已经拉完这些 binlog主库删了从库还没同步完从库会断住追不上重建或补同步非常痛苦第二如果实例开了 PITR 备份binlog 是恢复数据的基础清理前要确认备份链路已经把需要的 binlog 归档了。我的习惯是先执行 SHOW SLAVE STATUS 看 Seconds_Behind_Master 归零再清这一步别省。4.2 会话管理看全 SQL、终止阻塞进程会话管理用来查看当前正在执行的 SQL。页面右上角选择数据库实例和 command 类型默认是 query想查看所有进程选择 All。有一个必须记住的操作先勾选“完整 INFO”否则长 SQL 显示不全只看到截断的前半段排查问题容易误判。这个坑我踩过一次后面避坑章节会细说。如果定位到某条 SQL 一直在跑、占着连接或者锁着资源可以勾选该进程点“终止会话”。这个操作力度很重等于直接 kill 连接事务会回滚。终止前尽量确认一下这个连接是不是某个核心应用的长连接、业务是不是正在跑批量任务。误杀会造成应用报错别一看到耗时长的 SQL 就手痒先看清再动手。4.3 事务与锁信息从 trx_mysql_thread_id 到 THREAD ID 的对应关系锁信息排查是实例管理里最高频的场景。模拟一下锁等待的情况两个会话同时操作同一行-- 会话A开启事务并更新一行 BEGIN; UPDATE baidd.t2 SET enamebaidd WHERE id2; -- 会话B更新同一行被阻塞 UPDATE baidd.t2 SET enamedan WHERE id2;在 Archery 的锁信息里能看到等待事务的 SQL也就是被阻塞的那条 UPDATE同时能看到阻塞方的线程 ID。要解除阻塞就去“进程状态”里搜到这个线程 ID终止对应会话。这里的关键对应关系是事务信息里的 trx_mysql_thread_id就等于进程状态里的 THREAD ID。这个对应关系一定要记牢很多人 kill 错会话就是栽在这里后面避坑章节继续展开。top 表空间可以看到实例里前几个比较大的表排查磁盘占用时可以配合 binlog 清理一起看弄清是大表数据占盘还是 binlog 堆积占盘问题定位准确了再动手。4.4 账号管理与参数配置图形化操作的两个边界账号管理是纯图形化的创建数据库账号、删除账号、授权。授权时可以勾选增删改查、修改表结构等权限粒度比手写 GRANT 直观。参数配置可以修改实例的动态参数平台会记录修改历史哪个参数在什么时候被改过、改成多少都有痕迹。这两个功能把 DBA 日常的基础操作从命令行挪到了页面上对权限管控也有好处什么操作是谁做的在历史里能查到排查问题不用再去翻 shell 历史。不过要注意边界账号管理只覆盖账号和库表级权限不涉及 MySQL 之外的账号体系参数配置只支持动态参数需要重启实例才生效的参数改了也不会立即生效页面会提醒你但真正重启还是得走运维流程平台不会帮你重启实例。把边界搞清楚就不会产生“我在平台改了参数为什么没生效”的困惑。4.5 PTArchiver 归档三个月前的流水自动搬走很多线上流水表业务只需要最近三个月的数据三个月前的不删除但也没人查。这种表越来越大查询越来越慢还不能直接 DELETE因为大表 DELETE 会拖垮主库。PTArchiver 插件就是把 pt-archiver 这个工具封装到平台里配置好后自动归档甚至能做成定时任务无需人工干预。我的用法是先按时间条件做一次小范围归档测试观察主库负载确认没问题再扩大范围。不要上来就把三个月前的数据一把梭归档过程中锁和 IO 压力会让业务产生波动。归档的目标表要和源表结构一致归档完成后建议做一次数据量核对确认搬过去的行数和删除的行数对得上。这类操作属于典型的“慢工出细活”跑得快不如跑得稳。4.6 Binlog2SQL解析指定位置的 binlog 并生成回滚 SQLBinlog2SQL 把 binlog 解析可视化典型场景是误操作数据恢复。比如想知道 master-bin.000009 从 857 到 1183 位置之间执行了什么 SQL在页面填入实例、binlog 文件名、起始位置和结束位置点“获取 SQL”就能看到原始 SQL。要生成回滚 SQL点“flashback”按钮再获取一次平台会生成对应的反向 SQL还支持异步获取文件binlog 很大的时候不会卡住页面结果准备好了会通知你。注意两个硬限制第一binlog 格式必须是 ROWstatement 格式解析不准确第二DDL 操作无法回滚平台只能回滚 DML。误 DROP 一张表Binlog2SQL 救不了你平时靠备份和延迟从库兜底。还有一点指定位置如果不是事务边界解析结果可能不完整需要适当扩大范围。4.7 SchemaSync只比对表结构不比数据SchemaSync 解决的是多实例表结构同步问题比如测试库结构和生产库保持一致。它读取源库和目标库的 schema自动生成同步 SQL 和回滚 SQL。手册里的例子251 库下有多个表249 库下只有 t2点击比对后生成 249 相对 251 应该执行的 DDL同时生成对应的回滚 DDL。这里一定要记住它的边界只比对表结构不比数据。指望它发现数据差异的同学可以直接放弃。每次做结构同步前我也建议手动翻一眼生成的 DDL平台自动生成的脚本你不看就执行出问题只能怪自己。生成的回滚 SQL 也要留下来结构变更同样需要后悔药。5. Archery 避坑指南5 条实战排错记录5.1 SQL 检测报 error 但本地执行没问题现象开发把一条建表语句在本地测试库执行成功提交到 Archery 后 SQL 检测直接给出 error开发认为是误报在群里喊平台有问题。原因Archery 的规范规则不只看语法还检查主键、注释、字段长度等约定。本地能执行不等于符合规范很多临时表、内部表可能天然没这些约束但落到核心业务表上就跑不过去。解决点开检测结果看具体规则项对照修改主键、注释这类问题按提示补齐改完重新检测。别争辩“能跑就行”平台卡的是长期维护成本。顺带说一句把本地库的 sql_mode 和规范对齐能减少一半这类“本地能过、平台报错”的冲突。5.2 工单审核通过后找不到“回滚 SQL”现象工单审核通过后想下载回滚 SQL 留档但页面上没有“下载回滚 SQL”的按钮同事以为平台坏了重提工单还是一样。原因回滚 SQL 依赖检测阶段生成不是所有 SQL 都有回滚。SELECT 类、DDL 类工单无法生成回滚只有可逆的 DML 才会生成对应回滚语句。解决需要回滚能力的变更在提交工单时确认 SQL 是 DML 类型检测通过后先下载回滚 SQL 再执行别等执行完再回头找。DDL 变更没有回滚脚本只能靠备份和 SchemaSync 的回滚 DDL 兜底这个预期要提前建立。5.3 会话管理里 SQL 显示不全现象一条每小时跑一次的重 SQL 出现在会话管理里但文本被截断只看到前半段后面 WHERE 条件全部被吞掉无法判断是不是问题 SQL。原因页面默认没勾“完整 INFO”长 SQL 被截断展示这是为了降低页面渲染压力做的默认设置不是平台显示异常。解决在会话管理页面先勾选“完整 INFO”再刷新完整 SQL 会显示出来。这个操作要养成肌肉记忆排查问题第一步先勾这个不然每次都得返工。尤其遇到几千字节的长 SQL不勾完整 INFO 看到的信息量约等于没有。5.4 kill 错会话把正常业务连接断了现象锁等待排查时按照锁信息去终止会话结果把一个正在跑正常业务的连接杀了业务方瞬间报错比锁等待本身还严重。原因锁信息里会展示多个事务误把等待方的线程 ID 当成阻塞方的 ID或者把 trx_mysql_thread_id 和进程状态里的 THREAD ID 搞混没对上号就动手。解决先在事务信息里确认目标事务的 trx_mysql_thread_id再去“进程状态”里用这个 ID 精确定位核对 SQL 内容后再终止。宁可多花十秒核对也不要手滑。终止会话前再看一眼进程的 command 类型和连接来源 IP确认是预期目标再点按钮。这条我栽过从那以后每次 kill 前强制走一遍核对流程再也没有误杀过。5.5 Binlog2SQL 解析出来空白或无法生成回滚 SQL现象指定 binlog 位置获取 SQL结果空白或者点 flashback 生成回滚 SQL 失败页面没有任何有用的报错信息像黑匣子一样。原因最常见的是 binlog_format 不是 ROWstatement 格式解析不出可用结果这是头号原因其次是指定位置不在事务边界内导致解析结果不完整还有可能是这段区间里是 DDL 操作本身无法回滚。这三个原因经常混在一起出现排查起来费时。解决先确认实例 binlog_format 为 ROW这是前提条件再适当扩大解析范围到完整事务边界最后确认区间内是 DML。想用这个功能的同学把 binlog_format 先确认一遍这是典型的“配置没问题但就是出不来数据”的玄学现场实际上每个环节都有迹可循。6. 上线前把回滚 SQL 和定时执行用好一次可控变更的完整动作每次上线变更我有一套固定的动作这套动作在 Archery 上线后基本变成了硬性习惯。先说整体顺序工单审核通过后第一步先把回滚 SQL 下载下来存到当次变更的目录里文件名标注好日期和工单号。这一步不做好后面出了事就只能干瞪眼。高危或批量 SQL 一律选定时执行时间窗口我一般放在凌晨两点到四点这个时段业务量最低出问题影响面最小。执行过程中我会开着会话管理页面盯两分钟看看有没有异常阻塞。执行完成后先看平台的执行结果再核对影响行数如果和预估差太多先不要急着回滚而是查清楚为什么差是条件写错了还是数据环境变了确认原因后再决定动作。回滚这个动作也有讲究。我见过有人一着急直接点回滚执行结果回滚 SQL 本身也有问题。正确做法是执行完变更后先下载回滚 SQL 检查字段确认它确实能把刚才的变更还原。回滚 SQL 是平台根据 binlog 或解析生成的条件不完整的情况出现过。所以每次上线回滚 SQL 我都会打开看一遍确认 WHERE 条件完整影响行数合理。这套流程走完一次可控的变更才算闭环。从那以后我每次上线都强制走一遍下载回滚 SQL、核对字段、定时执行、看执行结果、核对影响行数。这套流程看起来多花五分钟但换来的是半夜不用被叫起来救火。Archery 把审核和回滚做成了平台能力剩下的执行纪律要靠自己希望这些经验帮到你。本文还有配套的精品资源点击获取