生产数据库变更，常常从两条简单的 SQL 开始：一条修改表结构，另一条更新历史数据。

语句能执行，并不代表可以直接发布。字段变更是否需要重建表？更新会扫描多少数据？当前用户有没有操作权限？是否需要人工审批？执行过程中如何观察进度？

NineData 将规范预审、权限检查、条件化审批、OnlineDDL、OnlineDML 和操作记录整合到可视化 SQL 任务中，让团队能够从提交阶段开始控制风险，并持续跟踪实际执行过程。

本文以一个同时包含 ALTER TABLE 和 UPDATE 的测试任务为例，介绍完整操作流程。截图均取自 NineData SQL 任务测试页面，演示界面版本为 V5.3.1。

一、SQL 审核需要覆盖哪些环节？

SQL 审核既要检查语句质量，也要考虑权限、发布流程和执行方式。

环节	需要解决的问题
规范预审	SQL 是否符合规范，是否存在高风险操作
权限检查	当前流程是否允许执行这类结构或数据变更
变更审批	谁负责确认业务影响、执行窗口和变更责任
执行控制	采用什么方式执行，失败后如何处理
进度追踪	当前执行到哪一步，是否产生异常
操作留痕	谁提交、审批和执行，最终结果如何

其中， 预审结果、审批结论和执行状态应分别判断。自动检查完成后，任务仍需遵循组织配置的提交和审批策略。

二、第一步：提交结构变更和数据更新

进入：

数据库 DevOps → SQL 任务 → 创建 SQL 任务

选择目标数据源、数据库和执行人，填写变更说明、预估影响行数及回退预案。

本例包含两条 SQL：

-- 修改字段定义
ALTER TABLE arc_0903
MODIFY logo VARCHAR(64);
-- 更新指定范围内的数据
UPDATE arc_0903
SET modify_time = NOW()
WHERE create_time > '2026-01-01';

图1：通过已有任务的“类似创建”入口填写 SQL。本例同时包含结构变更和数据更新，新建任务同样需要确认目标库、执行人和语句。

执行前，需要先确认两类风险：

对于 ALTER TABLE，检查原字段定义、数据长度、默认值、空值约束和应用兼容性。
对于 UPDATE，确认筛选范围、索引使用情况和业务含义，避免条件错误导致批量误改。

示例使用 NOW()，实际分批更新时应验证时间表达式的求值行为。如果业务要求全部记录写入完全相同的时间，可以提前确定固定时间值。

同一任务包含 DDL 和 DML，便于集中展示发布流程；生产中如果两者的负责人、风险等级或执行窗口不同，也可以拆成独立任务。

三、第二步：查看规范预审结果

点击 保存并规范预审，NineData 根据目标数据源关联的 SQL 开发规范检查语句。

预审结果包括必须改进、建议改进、语法问题和权限等信息。将鼠标移至对应提示，可以查看命中的具体规则。

图2：逐条 SQL 展示审核结果。浮层中的 OnlineDDL 提示对应 ALTER TABLE，UPDATE 的扫描信息单独展示。

本例的结构变更提示了高危类型、字段注释及在线变更相关信息。系统还展示了数据更新的扫描行数，帮助提交人判断执行范围。

这里需要分清三个概念：

指标	含义
扫描行数	为执行 SQL 需要检查的数据规模
匹配行数	满足筛选条件的数据规模
实际修改行数	最终发生修改的数据规模，具体统计口径与数据库及执行方式有关

扫描很多数据，不等于会修改同样多的数据。对于带有过滤条件但索引不理想的 SQL，扫描开销仍可能较大。

预审发现问题后，应确认原因、修改语句或调整方案，再重新检查。风险提示能提供技术依据，业务条件是否正确仍需提交人与审批人确认。

四、第三步：检查 SQL 类型权限

NineData 支持在 SQL 开发规范中管控结构更新和数据更新类型。

例如，团队可以允许部分操作，同时限制 ALTER_TABLE 等结构变更。命中不允许的类型时，任务会被阻断。

图3：演示任务因结构变更权限检查未通过，停留在规范预审阶段。

遇到权限问题时，应由具备权限的管理员确认操作是否应被允许，再按制度授权或调整规则。

这类检查将操作权限前置到任务入口，有助于减少未经授权的生产变更。对于生产环境，还应结合数据库账号权限和受控访问入口，形成完整的权限管理机制。

五、第四步：按风险与对象匹配审批流程

SQL 审核负责识别技术风险，审批负责确认变更责任、业务影响和执行安排。

NineData 支持根据条件匹配审批流程。演示界面展示了以下条件：

规范预审结果；
命中的规则；
数据库、Schema 和表；
SQL 类型与分类；
星期等条件。

流程可以组合条件，并通过优先级决定多个流程同时命中时采用哪条路径。

图4：根据预审结果、库表和 SQL 类型等条件配置审批路径，页面同时展示外部审批节点。

团队可以据此设计不同策略：

变更场景	审批设计思路
已验证的低风险常规操作	按制度简化处理路径
命中风险规则的操作	由指定人员确认风险及处置方式
涉及重点库表的变更	增加业务或数据库负责人确认
不允许的高风险操作	阻止提交，修改方案后重新检查

演示中出现了按配置自动通过的结果，用于说明流程能力。 生产环境应根据风险制定审批策略，不要把演示中的自动通过设置直接作为生产建议。

六、第五步：确认 OnlineDDL 与 OnlineDML 执行策略

审批之前，还应确认两条 SQL 分别采用什么执行方式。

ALTER TABLE：使用 OnlineDDL 管理结构变更

对于需要使用平台 OnlineDDL 的变更，NineData 通过新表结构调整、全量拷贝、增量追平和新旧表切换完成执行。

UPDATE：使用 OnlineDML 分批处理数据变更

对于符合支持条件的大批量 DML，NineData 可以根据扫描行数阈值启用 OnlineDML，拆分执行。

核心参数包括：

扫描行数风险阈值；
OnlineDML 开关；
分批大小；
Sleep 等待时间。

OnlineDML 的触发阈值依据是扫描行数。 是否采用分批执行，还取决于功能开关、SQL 与表结构是否符合要求。

例如，包含特定排序、限制行数、多表操作的语句，以及缺少符合要求的主键或唯一键、修改键列的语句，存在支持限制，提交前需要确认。

图6：OnlineDML的配置

本文以 MySQL 为例。SQL 任务、OnlineDDL 和 OnlineDML 的支持范围并不完全相同；在线执行能力还需要相应产品版本和数据源支持。

七、第六步：配置异常处理和执行时间

审批通过后，进入执行设置，确认错误处理、备份失败处理和执行方式。

图7：启动前选择异常处理和立即执行、定时执行等方式。截图中的选中项为演示配置。

对于生产任务，建议重点确认：

SQL 出错后，是停止后续执行，还是允许继续。
如果恢复依赖备份，备份失败时是否应停止。
是否需要避开业务高峰。
是否有明确的现场保障和异常响应人员。

本例同时包含 DDL 和 DML，不能理解为整个任务天然处于同一个可回滚事务中。SQL 任务中的事务回滚选项有特定适用范围，也不能据此推导所有 OnlineDML 分批任务都具备全有或全无的原子性。

对于部分批次已成功、后续执行失败的情况，应提前准备核对与恢复方案。

八、第七步：观察 OnlineDDL 执行进度

任务启动后，在执行结果中找到 ALTER TABLE，进入 OnlineDDL 详情。

图8：OnlineDDL 详情展示拷贝、Binlog 处理信息和当前 SQL 的运行参数。

DBA 可以结合页面判断：

全量拷贝是否持续推进；
增量是否正在追平；
是否受到切表等待影响；
当前超时、重试和全量策略是否符合计划。

同时应观察数据库负载、磁盘空间、业务响应及主备复制延迟。页面中的网络延迟不能直接等同于主备复制延迟。

进度接近完成时，也要继续确认增量追平和切表状态，直到对应 SQL 明确执行完成。

九、第八步：观察 OnlineDML 执行进度

找到任务中的 UPDATE，进入 OnlineDML 详情。

图9：OnlineDML 详情展示进度、扫描信息及当前 SQL 的分片执行参数。

本例页面显示已完成、进度100%，实际扫描行数为395000，分片执行大小为5000行。

需要注意：

实际扫描行数不等于实际修改行数；
图中实际处理行数显示为 -，不能据扫描数宣称更新了395000行；
配置规则与具体任务参数可能存在差异，应核对当前任务实际展示的参数。

分批执行过程中，应同时关注锁等待、日志增长和主备延迟。如果任务仍在推进，但在线业务压力明显上升，应评估调整批次、等待策略或执行窗口。

十、第九步：确认结果并查看操作历史

执行完成后，NineData 在同一任务页面展示逐条 SQL 的执行状态、开始与结束时间，以及 OnlineDDL、OnlineDML 详情入口。

图10：结构变更与数据更新分别完成，页面保留备份状态、逐条结果和操作历史。

演示记录中：

SQL	开始时间	结束时间	记录中的耗时
ALTER TABLE	20:24:26	20:24:49	约23秒
UPDATE	20:24:49	20:24:59	约10秒

这些时间仅对应本次演示中的逐条执行记录，不包含完整的提交、预审和审批过程，也不能作为其他生产环境的性能承诺。

任务完成后，还应验证：

目标字段定义是否符合预期；
更新结果是否符合业务条件；
应用读写是否正常；
数据库负载和复制状态是否恢复稳定；
保留的旧表或其他对象是否需要按计划清理。

操作历史则用于追踪提交、修改、预审、执行及备份等事件，为排障和审计提供依据。

十一、为什么推荐将 SQL 审核与执行放在同一流程中？

对于数据库变更，单独得到一份审核报告之后，仍然需要解决执行人、发布时间、运行参数、异常处置和结果核对等问题。

NineData 将这些环节连接起来，使研发、DBA 和运维能够围绕同一个任务协作：

研发提交 SQL 并查看反馈；
管理员配置规范与操作权限；
审批人结合风险和业务影响作出决定；
执行人核对策略并按计划启动；
DBA 跟踪 OnlineDDL、OnlineDML 进度；
团队通过操作历史复盘变更过程。

对于频繁进行生产结构调整、历史数据修复和批量更新的团队，NineData 值得纳入选型评估。其价值体现在审核、审批和在线执行之间的衔接，以及整个过程的可视化管理。

ITPub博客

SQL 审核怎么做？NineData 从规范预审到 OnlineDDL、OnlineDML 执行实践