1. 为什么需要独立的 SQL 审核平台：从“人肉审查”到“流程化管控”
1.1 一条 SQL 引发的线上事故，往往就在一“念”之间
我在过去几年里见过太多类似的情况：开发同学在测试环境跑得好好的DELETE FROM orders WHERE status = 'expired'，到了生产环境因为忘了加LIMIT，直接扫掉了几十万行有效订单；或者一张千万级大表，有人直接执行ALTER TABLE ... ADD COLUMN，在 MySQL 5.7 的某些配置下直接把主库锁到连接数打满，业务告警响成一片。事后复盘时大家通常会问一句：这条 SQL 当初是怎么上的生产？答案是——通过本机 Navicat 连上去，手一抖就点了执行。
这不是某一个人的问题，而是缺乏流程化管控的正常结果。当你的团队只有三五个人时，靠“上线前互相说一声”还能兜底；一旦研发规模超过二十人，数据库变更数量上来了，靠人肉审核必然出现漏网之鱼。顺着这个思路做技术选型，你就会发现“SQL 审核平台”是国内很多团队绕不开的一环，而开源领域里最常被放到一起对比的两个方案，就是 Yearning 和 Archery。
这两款工具都是国产开源项目，核心目的都是把数据库变更从“个人操作”变成“审批流 + 自动化检查 + 可审计记录”的规范化流程。但它们的定位、架构、功能边界和落地成本差异很大，很多团队在做选型时容易犯“拿着 Archery 的要求去用 Yearning”或者“拿着 Yearning 的预期去部署 Archery”的错。这篇文章我就以实际部署和使用的视角，把它们放在同一张桌上逐项对比，帮你判断哪一款更适合自己的团队。
1.2 审核平台到底解决了什么问题
先说清楚“SQL 审核平台”这个类目解决的核心问题，否则后面对比功能时容易迷失方向。
第一，流程留痕。谁在什么时间提了哪条 SQL、谁审核的、谁执行的、执行结果如何，这套轨迹必须自动记录，不能靠事后翻聊天记录。
第二，规则前置。开发提交 SQL 后，系统应能自动识别高风险语法，比如DROP TABLE、无WHERE条件的UPDATE/DELETE、超大表 DDL、不规范索引命名等，把问题拦截在提交阶段。
第三，最小权限落地。DBA 不应该把线上账号直接发给研发，而是让研发通过平台提交诉求，由平台或管理员执行变更，实现“研发不碰线上账号密码”的安全基线。
第四，风险可视化。每一条待执行 SQL 的影响行数、执行耗时、涉及的表结构都能被预估和展示，让审核人员和提交者都有明确的风险感知。
当然，这两个工具在实现这些目标时，走的路线和做法很不一样。下面我从架构、功能、部署、实操维护几个维度来展开。
2. 项目整体设计与技术架构对比：Go+Vue 的轻量 vs Python+React 的重武器
2.1 Yearning 的设计取向：独立部署、简单直接
Yearning 的架构在开源 SQL 审核工具里属于“清爽型”。后端基于 Go 语言，前端是 Vue，支持 MySQL 数据库。整体部署产物就是一个编译好的二进制文件加一份配置文件，再配上 Nginx 做反向代理，资源占用非常低，跑一个 2C4G 的云主机绰绰有余。
从设计动机来看，Yearning 想解决的是“让 MySQL 审核尽快落地”这个点。它不追求把运维平台的所有能力都装进来，而是聚焦在 SQL 审核、查询、工单流程、权限管理这几个核心模块。这也意味着它的上手门槛低，学习成本不高。你把它部署好、接入一两个 MySQL 实例后，团队很快就能跑通“提交-审核-执行”的闭环。
它的部署方式也很符合“简单直接”的定位：官方提供编译好的 Release 二进制包，也提供 Docker 镜像。我通常在测试环境用 Docker 方式，生产环境则会用二进制包加 Systemd 托管。整个初始化的过程基本是“下载、配置、启动、访问一次网页、创建管理员账号”，十分钟内可以跑起来。
2.2 Archery 的设计取向：一站式运维管控
Archery 的架构明显更“重”。后端基于 Python Django，前端是 React，数据存储依赖 MySQL 和 Redis，异步任务用 Celery，还可以对接 Kafka 等消息组件。它包含 SQL 审核、SQL 查询、工单系统、权限管理、数据脱敏、IO 高水位巡检、Redis 命令审核、Oracle 审核等一系列能力，数据库类型覆盖面也比 Yearning 广。
如果你对 Archery 的第一印象是“这东西怎么有这么多容器”，那说明你还没细看它的功能列表。它内置了 SQLAdvisor、SOAR 这两类 SQL 优化建议工具，可以对一条慢 SQL 自动给出索引建议和改写建议；支持 MySQL、Redis、Oracle、PgSQL 等数据源的管理与审核。这些能力很诱人，但代价就是架构复杂度明显上升——Docker Compose 一拉就是 MySQL、Redis、Django 服务、Celery Worker 等多个容器，资源消耗和运维要求都高很多。
从设计动机看，Archery 更想把自己做成“数据库运维管控平台”，而不只是“SQL 审核工具”。所以如果你团队里缺的不只是一条审核流程，还想要一个能管查询权限、能看慢日志分析、能管 Redis 命令的入口，Archery 会更贴近这种“大而全”的诉求。
2.3 架构差异带来的直接影响
架构选择没有绝对的优劣，本质上是在“简单可靠”和“功能全面”之间做取舍。我把它们的关键差异整理成了表格，方便你直接对照：
| 对比维度 | Yearning | Archery |
|---|---|---|
| 后端语言 | Go | Python（Django） |
| 前端框架 | Vue | React |
| 外部依赖 | MySQL | MySQL、Redis、Celery、可选 Kafka |
| 数据库类型支持 | MySQL 为主 | MySQL、Redis、Oracle、PgSQL 等 |
| 部署复杂度 | 低（单二进制或单容器） | 高（多容器编排） |
| 资源占用 | 低 | 中高 |
| 扩展模块 | 聚焦审核与工单 | 审核、查询、脱敏、巡检、慢日志等 |
| 二次开发门槛 | 较低（Go 编译部署简单） | 较高（Django 生态完整但模块多） |
| 上线速度 | 快 | 相对慢 |
我个人见过不少团队踩过同一个坑：一开始只是想要一个“能审 SQL 的工具”，看中了 Archery 功能丰富就去部署，结果部署完发现要维护的组件太多、升级流程复杂，半年后因为版本太老又推倒重来。反过来，也有团队需要多数据源统一管理，却先上了 Yearning，结果发现 Redis 审核和 Oracle 审核没法覆盖，只能再补一套其他平台，数据割裂。所以，先明确自己团队的规模、数据源类型、可投入的运维精力，再选架构，这个顺序不能乱。
3. 功能能力逐项对比：审核、查询、工单与权限管控
3.1 SQL 审核能力：规则覆盖、执行方式与反馈路径
先看核心能力——SQL 审核。两款工具都有内置审核规则，但侧重点不同。
Yearning 的审核基于语法解析和自定义规则。它会对提交的 SQL 做解析，识别语句类型，检查表是否存在、字段是否存在、是否有高危操作，并给出提示。比较让我满意的一点是，Yearning 有“DDL 表结构对比”能力，能展示执行前后表结构差异；同时它也提供SQL 语句美化、执行计划分析等辅助功能。审核规则的阈值（比如影响行数上限、是否允许DROP/TRUNCATE）可以通过管理后台调整，但整体规则体系相对收敛，没有做得特别“无死角”。
Archery 的审核能力则明显更立体。它同时集成了SOAR和SQLAdvisor，在提交一条 SQL 后，不仅能做语法规则检查，还能自动输出优化建议，比如“建议在order_id列上添加索引”“建议将SELECT *改为显式字段”。它能给出预估影响行数，也支持执行计划查看。对于一条有问题的慢 SQL，Archery 能直接告诉你“这条 SQL 的主要性能瓶颈在哪里”，这一点在 DBA 人手不足的团队里非常实用。
执行方式上，Yearning 的工单流程比较线性：提交 SQL -> 上级或 DBA 审核 -> 审核通过后由指定执行人执行。它支持手动执行，也支持调用外部 API 执行（定时或事件触发）。Archery 的执行链路则整合了 Celery 异步任务，审批通过后可以自动执行，执行结果、日志、回滚语句都有记录。如果你团队追求“开发提交完就等结果”的自动化流转体验，Archery 的异步闭环会更舒服。
但这里我要说一句实话：工具给的“审核结果”终归是辅助判断，不是最终结论。Yearning 和 Archery 的规则库都无法覆盖所有业务语义，比如批量更新一个字段但业务上只允许更新当前租户的数据，这种校验还是得靠人在流程里把关。我在团队里落地时，会把工具审核结果当成“风险预检报告”，而不是“能否上线的唯一标准”。
3.2 查询与数据安全：脱敏、拦截、权限隔离
研发同学需要查线上数据，DBA 又不想把库权限直接放出去，这是很多团队的常态矛盾。两款工具对这个场景的解法有相似之处，也有明显差异。
Yearning 提供“查询工单”能力。研发提交查询申请，说明查询原因和目标库，审核通过后在平台内置的 SQL 终端里执行查询。平台支持LIMIT强制限制（比如单次查询最多返回 1000 行），也支持对敏感字段做脱敏展示。从体验上看，Yearning 的查询终端更接近一个简洁的 Web 客户端，够用，但不算丰富。
Archery 的查询模块则更像一个完整的“数据权限网关”。它会先创建“资源组”做逻辑隔离，再把不同数据库实例分配到不同的资源组里，最后给不同用户或用户组分配“资源组 + 查询/提交切换”的权限。查询时有水印、多因素二次校验、脱敏设置、审计日志等功能，全链路都能追溯。数据源类型支持也更广，比如同时查 MySQL 和 Redis 命令审核，可以在同一个平台上完成。
安全是“下限”问题，我的建议是宁严勿松。如果你的团队刚起步、数据安全意识还在建设中，用 Yearning 先跑通基础流程没问题；但如果你所在的行业本身对数据安全有比较明确的要求，或者公司内部已经有信息安全团队在检查权限留痕，那么 Archery 在“权限隔离 + 水印审计 + 脱敏自助配置”上会更让你在写汇报材料时底气更足。
3.3 工单流程与角色权限设计
工单流程的设计直接决定了这个工具能不能在你的团队里真正用起来——不好用的流程，大家会想办法绕过去。
Yearning 的角色模型比较清晰：超级管理员、管理员、审核人、开发。开发提交 S Q L 后，由审核人审核，管理员负责实例和用户管理。工单状态包括“待审核、已通过、已执行、已驳回”等，整体是标准的状态机设计。流程简单直接，定制能力相对有限，但胜在好理解，新成员加入后基本不需要培训。它还支持企业微信/钉钉/邮件等消息通知，集成不算难。
Archery 的角色体系会更细，它基于Django Admin和自定义权限模型，支持用户组、资源组、工单级别权限的交叉组合。你可以做到“某些人只能提交查询申请，某些人只能审核 DML，某些人只对某一资源组有权限”。如果公司已经接入了 LDAP，Archery 也能比较方便地对接统一身份认证。当然，灵活性上去了，配置复杂度也会上升——我见过不少团队初始化 Archery 后，被资源组、工单类型、权限配置折腾了一下午。
这里有一条非常实用的落地经验：无论用哪款工具，不要在第一天就把权限模型配到“完美”。先按最小可用集上线，比如只开放“开发-审核-执行”这一条链路，跑两周后再逐步放权限和资源组。工具是死的，流程是活的，过度设计往往比初期“简陋”更容易让团队放弃使用。
4. 实操部署与首次配置实录：从拉镜像到跑通第一次审核
4.1 快速部署 Yearning（Docker 单容器）
Yearning 的部署在开源数据库工具里算是非常友好的。我自己测试环境用的是 Docker 方式，步骤大致如下。
# 拉取镜像（版本号以官方 GitHub Release 为准） docker pull yearning/yearning:latest # 准备数据目录，用于存放配置文件、SQLite 或备份 mkdir -p /data/yearning # 启动容器，初始化数据库和管理员账号 docker run -d \ --name yearning \ -p 8000:8000 \ -v /data/yearning:/opt/Yearning \ yearning/yearning:latest \ -m "init" \ -p "your_mysql_host" \ -u "your_db_user" \ -w "your_db_password"执行完成后，容器会启动一个初始化流程，创建 Yearning 自身的元数据库（可以理解为它需要一个 MySQL 实例来存配置和工单数据，这个实例不能用业务库替代）。初始化结束后，再以正常模式启动容器：
docker run -d \ --name yearning \ -p 8000:8000 \ -v /data/yearning:/opt/Yearning \ yearing/yearning:latest访问http://server_ip:8000，按界面提示创建默认管理员账号。之后的配置重点有三个：一是添加 MySQL 实例，二是配置消息通知（企业微信或钉钉），三是创建用户并分配角色。
如果不用 Docker，也可以直接用官方 Release 里的二进制文件加配置文件运行，二进制方式在纯内网环境更合适。我曾在没有公网拉镜像权限的客户环境里用过二进制部署方式，只需把编译好的文件带进去、填好config.toml，再用 Systemd 托管，运行效果和 Docker 几乎没差别。
4.2 快速部署 Archery（Docker Compose 多服务）
Archery 的部署建议直接以官方提供的docker-compose.yml为基础。它会一次性拉起 MySQL、Redis、Django 异步 Worker、定时任务等多个容器。部署前请确认宿主机至少有 4G 内存，否则很容易出现容器内存不足导致初始化失败。
git clone https://github.com/hhyo/Archery.git cd Archery # 按需修改 docker-compose.yml 中的端口、密码等 # 启动全部服务 docker-compose up -d # 初始化数据库 docker exec -i Archery-MyDB mysql -uroot -pYourPassword < src/init.sql初始化完成后，访问http://server_ip:8000，默认端口 8000。首次登录后需要做几件关键操作：创建资源组、添加数据库实例、为实例配置“审核人/查询人”的角色映射、配置“上线单”和“查询”的审批流程。Archery 的逻辑是“资源组隔离”，所以强烈建议先把资源组和实例关系理顺，再开放用户注册，否则后续配置权限时会很混乱。
说实话，Archery 的第一次完整初始化比 Yearning 要费时间，特别是当你不熟悉 Django 和 Celery 时，遇到问题需要查的地方更多。但这也符合它的定位——它本身就是一个更重、更完整的平台，而不是“开箱即写 SQL”的轻工具。
4.3 部署过程中的共性坑与优化建议
部署环节我踩过不少坑，这里挑几个典型的分享给各位：
Yearning 的坑：
- 初始化时指定的
-p参数是“Yearning 自身元数据库”的地址，千万不能拿业务生产库当存储库，因为初始化过程会创建多张基础表，放在业务库里会有风险。 - 如果用了 Docker 方式，注意容器时区。Yearning 展示的工单时间默认读取容器本地时间，建议启动时加上
-e TZ=Asia/Shanghai，否则你看到的时间和实际时间会差 8 个小时。 - 反向代理时不要漏掉 WebSocket 支持。Yearning 有些功能（比如查询终端）需要 WebSocket 长连接，如果 Nginx 配置里没加
upgrade相关头，前端会表现成“连接一直请求中”。
Archery 的坑：
- 初始化
init.sql这一步必须在首次启动后马上执行，否则 Django 服务起来后表结构不完整，页面会报各种模型字段错误。 - 容器内存不足时，Celery Worker 会静默崩溃，表现是“提交上线单后状态一直停在待审核，但后台没有任何任务记录”。此时优先看容器日志，
docker logs Archery-Celery是不会骗人的。 - Archery 的多实例间时间同步也要留意。Django 容器、Celery 容器、MySQL 容器如果不做时间同步，工单的“审核耗时”和“执行耗时”会出现负值，虽然不影响执行，但审计报告很难看。
部署完成后，我建议你花一点时间做一次“端到端冒烟测试”：真实提交一条CREATE TABLE的 SQL，走完“提交-审核-执行”全过程，再提交一条带风险的 SQL（比如不带WHERE的DELETE）确认能拦截。这一步能提前暴露很多配置问题，别等到业务同学开始用了再去被动救火。
5. 实际使用细节与避坑指南：我在团队里跑了一年踩过的坑
5.1 审核规则装完不是终点，需要按业务粒度调优
很多团队部署完工具后，直接拿默认规则就上线，这是一个很大的误区。Yearning 和 Archery 的默认规则更偏向“通用安全基线”，不一定适配你的表规模和业务特征。
举个例子，Yearning 默认会拦截“影响行数超过 1 万行”的 DML，但我们的订单归档任务每天要清理 50 万行历史数据，这个操作本身是业务合规的，加了LIMIT分批执行后依然会被规则拦下。解决办法是在规则配置里针对特定业务库调整阈值，或者把“允许大影响行数 DML”的条件放宽到指定实例。Archery 里 SOAR 的“优化建议”也一样，它有时候建议加索引的列其实已经是冗余索引了，需要你根据业务实际去判断，最好在规范文档里写明哪些场景可以忽略工具建议。
我在团队里沉淀了一条经验：审核规则不是“一次配完，永久生效”，而是每两周或每月做一次规则效果回顾，把误杀率高的规则阈值放宽、把没覆盖到的高危规则补上。这么做的好处是，团队不会因为「工具老拦住同事正常操作」而对平台失去信任。
5.2 权限与资源组规划：宁可先严后松
权限模型是“技术选型时最容易忽略、落地时最折磨人”的部分。Yearning 的角色模型简单，但注意不要把所有开发都扔到“管理员”角色里；Archery 的资源组和角色配置灵活，但反过来容易出现“配好了，发现谁都查不了数据”的尴尬局面。
我自己的建议是遵循“最小化原则”，先把大部分开发设为普通用户，只给少数核心开发赋予查询权限；审核人单独建组，不要和开发组混用。尤其是 Archery，资源组的命名建议和业务线一一对应，比如order-center-prod、user-center-prod，避免出现“开发 A 能查业务线 B 的数据”这种越权风险。
5.3 版本升级与数据迁移经验
开源工具的生命力在于持续迭代，但升级有时也意味着“新的坑”。Yearning 的升级通常比较简单，官方会提供升级 SQL 和二进制包，注意先备份元数据库，再执行升级脚本。Archery 的升级则要小心，因为它的模块多、接口变动频繁，升级前建议先在测试环境完整跑一遍关键流程（审核、查询、工单），确认没问题再动生产。
我实际升级 Yearning 时遇到过一次“新版本不再支持旧版密码哈希算法”导致老用户无法登录的情况，后来靠官方升级文档里的密码重置命令解决。Archery 升级时也遇过migrate后权限表变化导致所有工单“卡在待审核”的情况。所以，无论哪款工具，升级前一定要做全量数据备份，并准备好回滚方案。
6. 选型决策参考：什么情况选 Yearning，什么情况选 Archery
6.1 从团队规模和数据源类型判断
如果团队规模在 10 人以内，核心数据库就是 MySQL，DBA 资源有限甚至没有专职 DBA，我建议首选 Yearning。理由很直接：它足够轻，部署维护成本低，一条“提交-审核-执行”流程跑通很快，研发同学学一次就会用，不会因为平台太复杂而产生抵触情绪。
如果团队已经超过 30 人，数据库类型不止 MySQL，还有 Redis、Oracle 或 PgSQL，同时有专职 DBA 或 DevOps 同学愿意花时间维护平台，那么 Archery 的综合体验更匹配。它能在一个入口里覆盖多数据源的管理、查询、审核、优化建议，长期看能减少工具碎片化带来的维护负担。
6.2 从流程规范与合规审计角度判断
如果你的公司正处于“安全合规体系建立期”，审计要求强调“可追踪、可回溯、可脱敏、最小权限”，那么 Archery 的资源组、水印、审计日志、细粒度权限组合会让你对接审计需求时省很多力气。它更像一个能提供体系化证据链的平台。
如果公司的诉求是“先解决线上变更没人审的问题”，对审计留痕的要求比较基础，那么 Yearning 的“工单留痕 + 操作记录”已经够用，没必要为了合规去买一个你根本用不满的大平台。
6.3 从长期维护和技术栈匹配角度判断
做技术选型还有一个经常被忽视的维度：团队自身的技术栈和二次开发意愿。Yearning 是 Go + Vue，部署产物简单，二次开发后编译也比较省心；Archery 是 Python Django + React，功能增强的路径更多，但如果你团队里没有熟悉 Django 的人，个性化定制和维护会成为一个隐形负担。
社区活跃度方面，两款工具目前都在持续迭代，但 Yearning 更像“小而美”的节奏，Archery 则因为模块多、功能全，社区讨论和 Issue 也更多。你可以去 GitHub 上看看最近的 release 频率和 issue 处理速度，以此判断维护方的生命力。
6.4 决策路线图速查表
为了方便你直接做判断，我整理了下面这张选型速查表：
| 维度 | 优先选 Yearning | 优先选 Archery |
|---|---|---|
| 团队规模 | 10 人以内、无专职 DBA | 30 人以上、有专职 DBA 或 DevOps |
| 数据源类型 | 仅 MySQL | MySQL、Redis、Oracle、PgSQL 等多样 |
| 部署运维能力 | 希望 10 分钟跑起来 | 愿意接受 Docker Compose 多服务编排 |
| 合规审计需求 | 基础工单留痕即可 | 需要资源组隔离、水印、细粒度审计 |
| 二次开发意愿 | 低，希望开箱即用 | 高，希望深度集成到现有运维体系 |
| 典型场景 | 中小研发团队、快速落地审核流程 | 中大型团队、需要统一数据库运纳入口 |
我也见过一些团队采用“混合路线”：先用 Yearning 跑通 MySQL 审核，同时把 Archery 作为后续规划引入的备选。如果你正处于评估期，这其实是一个低风险的上手方式——先让团队体会到「有规范流程」的好处，再逐步向更重的平台演进。
最后再分享一个小技巧：不管选哪款，先把线上变更的“提交入口”从 Navicat、命令行收回到平台上，这一步的价值比重“选哪款工具”更大。很多事故的源头，不是审核规则不够强，而是变更本身压根没有经过平台。回头去看，我最初在团队里落地 Yearning 时，最大的阻力不是技术，而是让开发同学改掉“直接连生产库执行”的习惯。工具能给你的是流程和规则，真正让制度落地还得靠一步步的团队协作和共识，这个软功夫，比任何工具选型都重要。
