AI 时代，数据依然是最贵的

AI 可以写代码、生成图片、分析文档，甚至在几分钟内搭建一个应用。但当越来越多的业务开始接入 AI，一个容易被忽略的事实反而更加重要：

模型可以更换，代码可以重写，服务器可以重建，但生产数据库中的数据往往无法重新创造。

一条缺少 WHERE 条件的 DELETE，一次未经评估的表结构变更，或者一个误操作的 DROP TABLE，都可能让团队几个月甚至几年的积累瞬间归零。

所以在 AI 时代，企业最昂贵的资产依然不是模型，也不是服务器，而是数据。

数据库真正危险的，往往不是黑客

提到数据库安全，很多人首先想到攻击、漏洞和数据泄露。但在日常运维中，风险也经常来自内部操作：

开发人员执行了一条影响范围错误的 SQL；
测试环境的操作被误提交到生产环境；
大表直接执行 DDL，造成长时间阻塞；
查询没有合适索引，拖慢整个数据库；
数据库账号多人共享，无法追踪操作人；
敏感字段被随意查询、导出和传播；
SQL 上线依赖聊天记录与口头确认。

小团队常见的发布流程是：开发把 SQL 发到群里，DBA 或运维看一眼，然后登录服务器执行。业务规模较小时，这种方式似乎足够直接；随着数据库数量、参与人员和发布频率增加，它却很难回答下面这些问题：

谁可以操作哪个数据库？提交了什么 SQL？谁审核并批准？最终执行结果是什么？出现问题后能否追踪和回滚？

真正需要治理的，不只是数据库密码，而是每一次访问和变更的完整生命周期。

Archery 是什么

Archery 是一个开源的 SQL 审核与查询平台。它把查询、SQL 审核、上线审批、权限管理和操作审计集中到一个 Web 入口，而不只是提供另一个数据库客户端。

它的核心价值可以概括为三点：

把 SQL 上线从“人工看一眼”变成标准化流程；
让开发人员能够查数据，但不必持有生产库高权限账号；
把分散的数据库连接、权限和操作记录集中起来。

Archery 支持 MySQL、MariaDB、Microsoft SQL Server、Redis、PostgreSQL、Oracle、MongoDB、ClickHouse、Doris、Elasticsearch、OpenSearch、TDengine 等多种数据源。不过，不同数据库支持的能力并不相同，部署前应以项目 README 中的功能矩阵为准。

SQL 上线不能只靠“看一眼”

传统 SQL 审核高度依赖审核人的经验和当时的状态：SQL 太长容易漏看，发布频率高时难以逐条检查，不同人的判断标准也不一致，深夜紧急发布则更容易误判。

Archery 可以把数据库变更组织为一条可追踪的链路：

提交 SQL
  -> 自动审核
  -> 人工审批
  -> 执行上线
  -> 保存结果与操作记录

开发人员选择目标实例、数据库和上线时间后提交工单，不再需要直接登录生产数据库。审核规则可以提前发现缺少必要条件的 UPDATE 或 DELETE、不符合规范的表结构、高风险 DDL，以及可能影响大量数据的变更。

在 MySQL 场景中，Archery 可以配合 goInception 完成审核、执行、备份及生成回滚语句，并集成 SOAR、SQLAdvisor、SchemaSync、gh-ost、pt-online-schema-change 等工具。具体能力取决于所用数据库、组件安装情况和项目版本，不能把平台审核当成绝对安全保证。

审核平台的意义不是替人承担责任，而是在执行之前增加规则检查，在执行过程中留下记录，在出现问题后提供追踪线索。

查数据不等于交出数据库密码

开发人员需要查询生产数据排查问题，但直接开放数据库账号会带来误操作、越权访问和敏感数据泄露。如果完全不给权限，处理问题的效率又会很低。

Archery 提供了一种折中方式：开发人员通过浏览器进入平台，在授权范围内执行查询，而不是获得完整的数据库账号。平台可以集中管理：

用户、角色和资源组；
数据库实例与查询权限；
SQL 上线权限和审批流程；
查询记录与操作审计；
敏感字段的数据脱敏。

数据库权限由此从“把密码发给谁”，变成更细粒度的“谁可以在什么范围内，以什么方式访问哪些数据”。

但平台本身也会成为重要入口。部署后仍应启用最小权限、强认证和访问控制，并妥善保护 Archery 使用的数据库凭据。

数据库需要统一的资产视图

只有一两个数据库时，普通客户端通常够用。实例逐渐增多后，信息会迅速分散：表和字段分别属于什么业务、谁修改过结构、哪些 SQL 最慢、哪些账号长期未使用、当前是否存在长时间会话，都很难从单一连接信息中回答。

除了查询和审核，Archery 还提供数据字典、慢日志、会话管理、账号管理、参数管理和数据归档等能力。它不必替代所有专业数据库工具，但可以成为开发、运维和 DBA 之间的统一入口：

开发人员有固定的位置查询数据、提交 SQL；
运维和 DBA 可以集中管理权限、审批和执行记录；
团队能够看到数据库操作的来龙去脉，而不是依赖个人记忆。

为什么适配 Oracle Cloud ARM

我有一些自建服务运行在 Oracle Cloud ARM 实例上。当我准备部署 Archery 时，首先遇到的不是业务配置，而是容器及其依赖的架构兼容问题。

在 x86_64 主机上能够直接运行的镜像，到了 ARM64 环境可能会遇到：

镜像没有 ARM64 Manifest；
基础镜像或下载地址写死为 amd64；
依赖工具只有 x86_64 预编译二进制；
Dockerfile 中的安装路径与 CPU 架构绑定；
主应用能够启动，但某些审核或优化工具不可用。

因此，我 Fork 了 Archery，并修改构建与部署部分，目标是在保留 amd64 构建的同时，增加 ARM64 主平台支持：

ARM64 适配做了什么

这次工作的重点不是增加业务功能，而是建立可重复的多架构镜像构建流程。

1. 使用 Buildx 构建多架构镜像

GitHub Actions 工作流加入 QEMU 和 Docker Buildx，基础镜像与应用镜像都面向下面两个平台构建：

1 2	linux/amd64 linux/arm64

构建过程先发布对应架构的基础镜像，再让 Archery 应用镜像引用它，避免在 ARM 主机上拉到只包含 amd64 层的镜像。

2. 按目标架构处理依赖

原构建流程中存在写死的 amd64 下载地址、库目录和二进制文件。适配后，Dockerfile 通过 TARGETARCH 区分 amd64 与 arm64，为 Oracle Instant Client、系统库路径等选择对应架构，并在构建阶段为目标平台编译 my2sql。

这比在 ARM 主机上通过模拟强行运行完整 amd64 镜像更可控，也让同一套构建文件能够继续服务 x86_64 环境。

3. 明确 ARM64 的能力边界

多架构镜像不代表所有第三方工具都已原生支持 ARM64。当前 Fork 中，SQLAdvisor、SOAR 和 Archery 使用的旧版 Mongo Shell 因上游仅发布 amd64 二进制，在 ARM64 镜像中会被标记为不可用。

这点必须说清楚：ARM64 适配解决的是 Archery 主应用及一组关键依赖的构建与运行问题，而不是承诺功能矩阵中的每项能力在两个架构上完全一致。部署前应根据自己的数据库类型和所需工具做实际验证。

小团队更需要可执行的规则

SQL 审核平台并不是大公司的专属。大公司通常有 DBA、发布平台、备份制度和明确的职责分工；小团队却经常由同一个人同时负责开发、运维和数据库，权限更集中，误操作后也缺少第二道防线。

一套工具不必做得很重，但至少应该落实这些底线：

开发人员不直接持有生产库高权限账号；
高风险 SQL 在执行前经过自动检查和人工复核；
重要变更留下审批与执行记录；
查询和变更操作能够追踪到人；
关键数据库定期备份，并真正演练过恢复；
高风险 DDL 预先评估锁、容量和执行时间；
生产变更准备可验证的回退方案。

Archery 可以帮助团队建立前四项流程，但它不能替代备份、恢复演练、监控告警和灾难恢复。审核通过也不等于 SQL 一定不会产生业务风险。

AI 越强，数据库治理越重要

AI 正在降低代码和 SQL 的生产成本。过去需要几天完成的功能，现在可能几个小时就能生成；接下来，表结构、迁移脚本、发布工单甚至部署动作也会越来越自动化。

速度提高后，关键问题不再只是“AI 能不能生成 SQL”，而是：

谁来约束它生成的 SQL，又由谁确认这条语句适合真实的生产环境？

模型可以生成语法正确的 SQL，却未必了解生产数据规模、流量峰值、表之间的隐性依赖，也无法独自承担误删数据的责任。更合理的自动化链路应该是：

AI 生成 SQL
  -> 规则审核
  -> 影响范围与执行计划评估
  -> 人工或策略审批
  -> 受控执行
  -> 全程审计

AI 不是数据库治理的替代者。恰恰相反，代码和变更生成得越快，进入生产环境之前的安全门槛越应该明确。

写在最后

在 AI 时代，我们很容易被模型参数、GPU 数量和推理速度吸引。但对一个真正运行中的业务来说，最重要的资产往往安静地躺在数据库里：客户、订单、交易、库存、财务记录，以及多年积累下来的每一个业务状态。

模型可以更换，代码可以重构，服务器可以迁移。数据一旦丢失，很多时候无法重来。

所以我仍然相信：

AI 时代，数据依然是最贵的。

保护数据的第一步，就是不要让每一次数据库操作都成为一次赌博。