简介《archery使用手册》是一份面向DBA、运维工程师及后端开发者的SQL审核与MySQL运维实操文档帮助读者系统掌握Archery平台在SQL审核、优化与实例管理方面的核心用法。资源包内含1个doc文件大小约1.2MB以图文步骤形式组织内容便于按章节查阅与对照实践。手册围绕SQL审核、SQL优化、实例管理与工具插件四大模块展开涵盖建表主键与注释规范检查、高危语句自动驳回、定时执行与钉钉通知、慢SQL统计与执行计划分析、binlog清理、会话与事务管理、锁信息排查、账号授权及动态参数配置等要点并给出开发与测试环境的审核流程示例。工具插件部分介绍了PTArchiver数据归档、Binlog2SQL解析回滚以及SchemaSync结构同步的用法与限制。目前已有1477人学习适合需要提升数据库管理效率与安全性的技术人员参考。1. 从一次线上阻塞说起Archery 到底解决什么问题凌晨两点被叫起来处理数据库阻塞登上一台台机器敲SHOW PROCESSLIST翻半天才定位到一条没走索引的 UPDATE——这种场景做 MySQL 运维的多少都遇到过。Archery 就是冲着这类痛点来的它把自己定位成 SQL 审核查询平台同时把日常 MySQL 运维里那些零散的命令行操作收进一个 Web 界面。SQL 审核、SQL 优化、实例管理、工具插件四大块功能覆盖了从开发提交 SQL 到 DBA 排查问题的完整链路。适合谁用研发提交工单前自查、测试环境上线前审核、DBA 日常巡检和应急排查都能落到具体操作上。它不是银弹但能把「审核靠人肉、排查靠记忆」的现状拉到一个有记录、可回溯的流程里。2. SQL 审核与优化从语法解析到执行计划2.1 审核规则是怎么生效的Archery 的 SQL 审核核心是对提交的 SQL 做语法解析再拿解析结果去匹配自定义规则集。语法解析这一层负责识别语句类型DDL/DML、表名、字段、索引引用等结构信息规则层则判断这些结构是否满足预设规范。常见的默认规则包括建表必须有主键、表和列必须有注释、禁止SELECT *、WHERE 条件必须走索引列等。高危语句比如无 WHERE 的 DELETE 或 UPDATE会被直接驳回不进入人工审核环节。规则集可以按实例或按环境配置不同强度。开发环境通常宽松些允许一些实验性语句通过生产环境则收紧把DROP TABLE、TRUNCATE这类操作直接拦掉。审核结果分三档error 级别直接阻断提交warning 级别提示但可继续notice 级别仅记录。这个分级机制让审核既有约束力又不至于把正常开发卡死。2.2 提交一条 SQL 工单的完整动作假设研发同学写完一个建表语句要提交到开发环境。操作路径是这样的-- 待审核的 SQL 文件内容示例 CREATE TABLE order_detail ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单编号, product_id int(11) NOT NULL COMMENT 商品ID, quantity int(11) NOT NULL DEFAULT 0 COMMENT 数量, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单明细表;在 Archery 界面选择目标实例和数据库把 SQL 贴进工单框点「SQL 检测」。如果返回 error说明有规则没通过比如漏了主键或注释按提示改完再提交。检测通过后点「SQL 提交」工单进入审批流。审批流按环境不同有两条典型路径。开发环境是研发工程师发起、项目经理审批测试环境是测试同事从 Git 取开发提交的 SQL 文件在测试环境发起审核并自行审批执行。审批人登录后右上角通知按钮会亮点进去能看到待办工单。最后一级审核通过后执行方式有两个选项立即执行或定时执行。定时执行适合安排在业务低峰期跑 DDL避免锁表影响线上。回滚是审核流程里容易被忽略但很关键的一环。工单执行后可以在详情页点「查看回滚 SQL」或「下载回滚 SQL」。Archery 会根据原始语句生成对应的逆向操作比如 CREATE TABLE 对应 DROP TABLEALTER TABLE ADD COLUMN 对应 DROP COLUMN。但要注意回滚 SQL 不是万能的——如果 DDL 执行后已经有数据写入回滚可能丢数据所以执行前确认业务影响面是必须动作。2.3 SQL 优化建议怎么读「SQL 优化」功能入口独立于审核流程适合拿一条已经在跑的慢查询来分析。操作很简单把 SQL 贴进去点分析然后看报告。报告里会给出执行计划的关键信息——用了哪个索引、扫描行数、是否出现 filesort 或 temporary table。拿一条典型语句举例SELECT * FROM baidd.emp WHERE enamedan_1;分析报告大概率会提示两点一是SELECT *需要改成具体字段减少不必要的数据传输二是确认ename列上有没有索引没有的话建议加上。把SELECT *改成SELECT id, ename, dept_id之后再分析结果就会变成 OK。这个对比很直观适合用来给团队做 SQL 规范培训的案例。慢日志模块是另一个入口。它把 MySQL 慢查询日志里的记录拉出来做统计按执行次数、平均耗时、扫描行数排序。排查性能问题时先看慢日志里哪条 SQL 出现频率最高、耗时最长再拿那条 SQL 去优化模块里分析形成闭环。常见做法是每周过一遍慢日志 Top 20把新增的慢查询挑出来处理掉避免积压。注意SQL 优化模块给出的建议基于执行计划和规则库不是数据库真实运行时的全部信息。如果表数据分布倾斜严重或统计信息过期建议先ANALYZE TABLE再重新分析。3. 实例管理会话、事务与锁的排查路径3.1 会话管理里的关键操作实例管理默认只有管理员账号有权限这个设计合理——普通研发能看实例状态就够了终止会话这种操作必须收口。进入会话管理后右上角选择目标实例和 command 类型。默认是 query只看正在执行的查询排查问题时切到 All把所有进程都拉出来。这里有个容易翻车的点不勾「完整 INFO」的话SQL 语句显示不全长语句会被截断你看到的可能只是前半截误判成另一条 SQL。所以排查阻塞时第一件事就是勾上完整 INFO。定位到问题 SQL 后点「终止会话」就能 kill 掉对应线程。但 kill 之前要确认两件事这条会话是不是真的在阻塞别人以及 kill 掉之后业务侧有没有重试机制。直接 kill 主库上的写会话可能导致业务报错稳妥做法是先跟业务方确认。3.2 事务和锁的联动排查事务信息页展示当前运行的事务关键字段是trx_mysql_thread_id它对应进程状态里的 THREAD ID。如果发现某个事务长时间未提交拿这个 ID 去进程状态里搜找到对应会话后终止。锁信息的排查更依赖这个联动。模拟一个锁等待场景会话 A 执行BEGIN; UPDATE baidd.t2 SET enamebaidd WHERE id2;不提交会话 B 执行UPDATE baidd.t2 SET enamedan WHERE id2;被阻塞。在 Archery 锁信息页能看到等待事务的 SQL即被阻塞的那条和阻塞方的线程 ID。拿到阻塞方线程 ID 后回进程状态页搜索该 ID终止会话锁等待解除。这个流程比在命令行里反复切窗口敲SHOW ENGINE INNODB STATUS要直观得多尤其是多个锁等待交织的时候图形化展示能省不少时间。但要注意锁信息页展示的是当前瞬间的快照如果锁等待已经解除页面刷新后就看不到了所以发现异常要尽快截图或记录。3.3 binlog 清理与账号管理磁盘空间告急时清理 binlog 是最快的释放手段之一。在实例列表里选中某个 binlog 文件执行清理后该文件之前的所有 binlog 都会被删除。这个操作不可逆执行前必须确认从库是否已经同步完这些 binlog、有没有基于 binlog 的恢复需求。如果主从延迟较大清理掉从库还没同步的 binlog 会导致主从断裂这是血泪教训级别的坑。账号管理模块把CREATE USER、GRANT、ALTER USER这些命令图形化了。建完账号后需要单独授权可以按库或按表粒度给增删改查、改表结构等权限。修改密码和删除用户也在同一界面。相比手敲 GRANT 语句图形界面的好处是权限变更留痕谁在什么时候给谁授了什么权限记录可查。4. 工具插件归档、回滚与 Schema 同步4.1 PTArchiver 做数据归档线上流水表只保留最近三个月数据是常见需求三个月前的归档到历史库或冷存储。PTArchiver 插件把 pt-archiver 这个命令行工具包装成了可视化配置。在界面上指定源表、目标表、归档条件比如create_time DATE_SUB(NOW(), INTERVAL 3 MONTH)、每次归档行数和间隔时间提交后可以立即执行或配成定时任务。参数配置里有两个值需要留意--limit控制每批归档行数默认 1000 行大表归档时调小这个值能降低对线上查询的影响--sleep控制每批之间的间隔秒数配合 limit 使用避免归档操作把磁盘 IO 打满。归档过程中如果源表有写入pt-archiver 默认用--purge模式边归档边删除需要确认业务能接受归档期间源表数据短暂不一致。4.2 Binlog2SQL 生成回滚 SQLBinlog2SQL 插件解决的是「误操作后怎么恢复数据」的问题。它从 MySQL binlog 里解析出指定位置区间的 SQL支持生成原始 SQL、回滚 SQL、去掉主键的 INSERT 语句等。操作流程选择实例和 binlog 文件填起始和结束 position点「获取 SQL」看到原始操作再点「flashback」按钮生成回滚语句。# 底层调用的命令逻辑示意 python binlog2sql.py -h127.0.0.1 -P3306 -uuser -ppassword \ -d baidd -t t2 --start-filemaster-bin.000009 \ --start-pos857 --stop-pos1183 --flashback关键参数说明--start-file和--stop-pos界定解析范围范围越小解析越快--flashback是生成回滚 SQL 的开关不加这个参数输出的是原始 SQL-d和-t限定库表不指定则解析范围内所有库表。生成的 INSERT 会变成 DELETEUPDATE 会交换 SET 前后的值DELETE 会变成 INSERT。注意Binlog2SQL 只能回滚 DML 操作DDL 语句无法回滚。而且回滚的前提是 binlog 格式为 ROW如果 binlog_format 是 STATEMENT解析出来的 SQL 可能不完整。执行回滚前务必在测试环境验证一遍回滚 SQL 的正确性。4.3 SchemaSync 比对表结构SchemaSync 用于比对两个库的表结构差异自动生成同步用的 DDL 和对应的回滚 SQL。注意它只比对表结构不比对数据。典型场景是开发库和测试库结构不一致需要把开发库的变更同步到测试库。操作时选择源库和目标库点比对界面会列出目标库相对于源库缺少的表、缺少的列、索引差异等并生成对应的ALTER TABLE语句和回滚语句。比如源库有t1、t2、t3三张表目标库只有t2比对结果会生成创建t1和t3的 DDL回滚 SQL 则是对应的DROP TABLE。这个工具适合在版本发布前做结构一致性检查但不适合直接在生产环境执行生成的 DDL——生产环境的 DDL 还是要走审核流程确认锁表时间和影响范围。5. 几个容易翻车的细节和我的使用习惯5.1 审核规则误报与规则集调优现象一条正常 SQL 被审核规则拦下提示「未使用索引」但实际查询走了索引。原因通常是规则引擎基于语法解析判断无法感知运行时的索引选择或者统计信息过期导致解析结果偏差。解决方式是在规则集里把该规则对该实例调成 warning 级别或者先ANALYZE TABLE更新统计信息再重新检测。规则集不是越严越好生产环境收紧、开发环境放宽是更务实的做法。5.2 定时执行 DDL 的时间窗口现象定时执行的 ALTER TABLE 在业务高峰期触发导致锁等待。原因是定时任务配置的时间没有避开业务高峰或者 DDL 执行时间超出预期。解决方式是定时执行前先评估表数据量和 DDL 类型大表加字段尽量用ALGORITHMINPLACE并在低峰期执行。我一般会把定时执行时间设在凌晨 2 点到 4 点之间并提前一天在群里通知相关方。5.3 回滚 SQL 的适用边界现象执行完 DDL 后想回滚发现回滚 SQL 执行报错或丢数据。原因是 DDL 执行后表里已经有新数据写入回滚操作比如 DROP COLUMN会连带删掉这些数据。解决方式是在执行 DDL 前确认业务影响面能不停机加字段就不要用会锁表的操作。回滚 SQL 是后悔药但不是所有场景都能吃。5.4 会话终止的连锁反应现象kill 掉一个会话后业务侧报连接异常或者触发重试导致更多并发。原因是 kill 的是主库上的写会话业务没有做好重试和降级。解决方式是 kill 前先确认会话状态是等待锁还是正在执行大事务优先 kill 等待中的会话而不是执行中的。如果必须 kill 执行中的写会话提前跟业务方打招呼。5.5 binlog 清理与主从同步的时序现象清理 binlog 后从库报错主从同步中断。原因是清理掉的 binlog 从库还没同步完。解决方式是在清理前用SHOW SLAVE STATUS确认从库的Relay_Master_Log_File位置只清理从库已经同步完的 binlog。更稳妥的做法是保留最近 7 天的 binlog清理更早的。从那以后我每次清理 binlog 前都强制走一遍从库同步状态检查确认Seconds_Behind_Master为 0 且从库读取的 binlog 位置在清理范围之后才动手。这套流程看起来繁琐但比主从断了再重建要省事得多。希望帮到你。本文还有配套的精品资源点击获取