周恰恰前阵子帮团队把数据库变更环节规范了一下，核心引入的开源工具是 Yearning，部署方式选了 Docker Compose。这篇文章把我从环境准备、容器编排、首次初始化的完整过程，到后来线上使用遇到的坑都整理出来。适合正在准备引入 SQL 审核的 DBA、后端负责人，以及想搞明白 Yearning 到底怎么跑起来的运维同学。
Yearning 本质上是一套带 Web 界面的 SQL 审核与执行平台，承接的是数据库变更里最难管的一段：开发写好的 SQL 怎么经过审核、由谁执行、执行前后怎么留痕、出了问题怎么回滚。以前很多团队的流程是开发在群里喊一句“帮我跑下这条 SQL”，DBA 拿到手直接在线上执行，没有任何审批记录。小问题靠运气，出大事连是谁执行的、执行前长什么样都说不清。部署 Yearning 之后，这条链路就变成线上化的工单系统：有人提交、有人审核、有人执行，全程留痕。
仓库地址在 GitHub 上能直接找到，镜像也有官方版本，不需要自己再包一层。用 Docker 部署的意义不只是“起个容器”这么简单，它让 Yearning 的代码、配置、依赖和底层数据库环境彻底解耦，升级、回滚、迁移都变成几条命令的事。下面我按实际操作顺序来写，你可以直接对着敲。
1. 项目概述：Yearning 到底解决了什么问题
1.1 没有审核流程时，数据库变更有多失控
先还原一个我见过太多次的现场。业务上线新版本，后端开发需要给订单表加一个索引，还要把一批历史订单的状态批量修正。他写好 SQL 之后，直接在 Navicat 里连上生产库执行了。执行完发现 update 语句里的 where 条件写漏了一个状态字段，导致几千条正常订单被误改。等发现问题的时候，离线备份已经是前一天晚上的，当天白天的数据只能靠脑子回忆去补。
这不是能力问题，而是流程缺失。人总有手滑的时候，SQL 越复杂、影响的数据越多，出错的概率越大。更隐蔽的是执行前的审查环节：这段 SQL 会不会导致锁表？影响行数是不是被刻意限制过？涉及的表是不是被列为敏感表？这些单靠一个人盯着屏幕看，很难每次都看全面。Yearning 这类 SQL 审核平台，就是用系统化的规则去强制卡这道关口。
Yearning 做的事，说起来并不玄乎：把数据库变更分成“提交、审核、执行、回滚、审计”五个环节。开发写好 SQL 后在网页上提交工单，系统自动做语法解析和规则检查；审核人看到工单后在线审批，也可以驳回要求修改；审核通过后由有权限的人点击执行，平台负责把 SQL 真正跑到目标数据库上；如果操作有风险或者执行后需要回退，平台还能基于 binlog 生成回滚语句。每一步操作记录都留在系统里，随时能查。
1.2 Yearning 的核心功能模块
如果只看官网截图，会觉得 Yearning 的界面和常见的工单系统差不多。但它的功能模块拆开看，每个都对应一个真实的运维场景：
| 功能模块 | 实际用途 | 谁最需要 |
|---|---|---|
| SQL 审核工单 | 开发提交上线 SQL，DBA 或技术负责人审批后执行 | 后端开发、DBA |
| SQL 查询 | 授权的只读查询入口，用于代替开发直连数据库查数据 | 开发、测试、运维 |
| 敏感操作规则 | 检测不带 where 的 update/delete、禁用 drop、限制影响行数 | DBA |
| 回滚与审计 | 执行后自动生成回滚语句，保留操作前后记录 | DBA、安全合规 |
| 用户与权限 | 按资源组划分数据源范围，不同角色不同权限 | 管理员、团队负责人 |
审核规则是 Yearning 比较有特点的地方。它不只是简单看关键字，而是能识别出“你这是 update 语句，但没有 where 条件”，或者“你这条 delete 会影响整张表”。这种能力在自研的审核系统里往往要花不少精力才能做到，Yearning 直接把规则内置了，并且允许管理员自定义。
1.3 为什么我选了 Docker 部署而不是裸机二进制
Yearning 官网也提供二进制包，但部署到 Linux 服务器上要自己处理 systemd 服务、配置文件目录、版本升级路径，尤其是后端存储的 MySQL 版本兼容问题经常让人头疼。用 Docker 不是逃避问题，而是把环境差异收敛到镜像层，让平台本身只关注业务逻辑。
具体到我个人的选择依据，主要是三点。第一，官方镜像会跟随版本更新，升级时只需要拉新镜像重建容器，代码和配置不会被环境搞乱。第二，用 Docker Compose 可以把 Yearning 和它的元数据库一起编排，新环境部署时一条命令拉起，不用每次手工初始化数据库再写一堆启动脚本。第三，Yearning 本身是有状态的系统，它的配置、工单记录、审计日志都存在 MySQL 里，把 MySQL 数据目录外挂到宿主机磁盘，后续无论是容器迁移还是备份恢复都简单很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前准备：先把版本和目录规划清楚
2.1 基础环境与 Docker 版本要求
Yearning 是前后端一体的 Web 服务，自身资源消耗不大，但它依赖的 MySQL 容器至少要几百 MB 内存。所以部署这台机器建议 2 核 4G 起步，如果业务量大或者工单并发高，再把配置往上提。最低 1G 内存的机器也能跑起来，但 MySQL 一启动可能就吃掉大半内存，系统会不停触发 swap，体验很差。
Docker 环境方面，当前官方推荐使用 Docker Compose V2 语法，也就是 docker compose 命令。如果你的机器上还只有老版本的 docker-compose，也没关系，大部分 compose 文件是兼容的，只是个别新特性用不了。部署前先确认两个命令能用：
bash复制docker --version
docker compose version
如果 docker compose 提示找不到命令，大概率是 Docker 版本比较旧，或者没有安装 compose 插件。建议先升级 Docker 到较新版本再继续，因为后面我可能会用到 depends_on 条件等待这类相对新的特性。
对于需要从 Docker Hub 拉镜像的机器，如果网络