企业官网建设流程全解析

简介：《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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

在 Archery 界面选择目标实例和数据库，把 SQL 贴进工单框，点「SQL 检测」。如果返回 error，说明有规则没通过，比如漏了主键或注释，按提示改完再提交。检测通过后点「SQL 提交」，工单进入审批流。

审批流按环境不同有两条典型路径。开发环境是研发工程师发起、项目经理审批；测试环境是测试同事从 Git 取开发提交的 SQL 文件，在测试环境发起审核并自行审批执行。审批人登录后右上角通知按钮会亮，点进去能看到待办工单。最后一级审核通过后，执行方式有两个选项：立即执行或定时执行。定时执行适合安排在业务低峰期跑 DDL，避免锁表影响线上。

回滚是审核流程里容易被忽略但很关键的一环。工单执行后，可以在详情页点「查看回滚 SQL」或「下载回滚 SQL」。Archery 会根据原始语句生成对应的逆向操作，比如 CREATE TABLE 对应 DROP TABLE，ALTER TABLE ADD COLUMN 对应 DROP COLUMN。但要注意，回滚 SQL 不是万能的——如果 DDL 执行后已经有数据写入，回滚可能丢数据，所以执行前确认业务影响面是必须动作。

2.3 SQL 优化建议怎么读

「SQL 优化」功能入口独立于审核流程，适合拿一条已经在跑的慢查询来分析。操作很简单：把 SQL 贴进去，点分析，然后看报告。报告里会给出执行计划的关键信息——用了哪个索引、扫描行数、是否出现 filesort 或 temporary table。

拿一条典型语句举例：

SELECT * FROM baidd.emp WHERE ename='dan_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 ename='baidd' WHERE id=2;不提交；会话 B 执行UPDATE baidd.t2 SET ename='dan' WHERE id=2;被阻塞。在 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 生成回滚 SQL

Binlog2SQL 插件解决的是「误操作后怎么恢复数据」的问题。它从 MySQL binlog 里解析出指定位置区间的 SQL，支持生成原始 SQL、回滚 SQL、去掉主键的 INSERT 语句等。操作流程：选择实例和 binlog 文件，填起始和结束 position，点「获取 SQL」看到原始操作，再点「flashback」按钮生成回滚语句。

# 底层调用的命令逻辑示意 python binlog2sql.py -h127.0.0.1 -P3306 -uuser -p'password' \ -d baidd -t t2 --start-file='master-bin.000009' \ --start-pos=857 --stop-pos=1183 --flashback

关键参数说明：--start-file和--stop-pos界定解析范围，范围越小解析越快；--flashback是生成回滚 SQL 的开关，不加这个参数输出的是原始 SQL；-d和-t限定库表，不指定则解析范围内所有库表。生成的 INSERT 会变成 DELETE，UPDATE 会交换 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 类型，大表加字段尽量用ALGORITHM=INPLACE，并在低峰期执行。我一般会把定时执行时间设在凌晨 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 位置在清理范围之后，才动手。这套流程看起来繁琐，但比主从断了再重建要省事得多。希望帮到你。

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