告别“一刀切”，让 SQL 审核真正懂业务

一、行业痛点：内置规则难以满足动态多变的业务需求

在数据库治理与 SQL 审核领域，一个普遍的困境是：规则固化与业务多变之间的矛盾。当前市面上大多数 SQL 审核工具仅提供内置规则，这些规则往往是“通用最佳实践”，却无法适应不同企业、不同业务线的独特要求：

• 金融行业可能严格要求所有交易表必须包含审计字段

• 电商系统可能禁止在高峰期执行特定类型的 DDL

• 数据平台可能要求所有查询必须包含租户隔离条件

• 团队内部规范如强制使用语义化别名、禁止某些函数等

这些带有强烈业务属性的规范，恰恰是内置规则无法覆盖的盲区。企业要么妥协于通用规则，要么依赖人工评审——效率低下且容易遗漏。这也是为什么 “SQL 审核规则是否支持高度自定义”，正在成为数据库治理工具的核心能力之一。

今天就和大家详细聊一聊：如何打破桎梏，使用DBdoctor自定义SQL 审核能力，打造完全适配自家业务的专属规则！

二、DBdoctor ：灵活、简单、快速的自定义 SQL 审核

DBdoctor 从根本上解决了这一问题，提供了一套 “可编程”的 SQL 审核规则体系，让研发团队能够自主定义贴合自身业务场景的规范，真正实现“SQL 质量内建”。

核心特性

• 灵活适配：从语法级到语义级，从表结构到执行计划，全方位自定义

• 简单易用：可视化配置结合脚本编写，技术人员快速上手

• 实时生效：规则热更新，无需等待产品迭代，即时响应业务变化

• 多引擎统一：一套自定义体系覆盖 MySQL、PostgreSQL、SQL Server 等多数据库

// 业务场景：金融系统要求所有表必须包含创建时间、更新时间字段let requiredColumns = ["create_time", "update_time"];let missingColumns = [];for colName in seq.keys(data.dbMetaInfo.dbTableInfoMap[tableName].allColumnMap) {    let found = false;    for reqCol in seq(requiredColumns) {        if (colName == reqCol) {          found = true;break;        }    }if (!found) {        missingColumns.push(reqCol);    }}if (!is_empty(missingColumns)) {        return createRuleCheckInfo(true, `表 ${tableName} 缺少必要字段：${join(missingColumns, ", ")}`);}

技术优势：

✅ 规则实时编译，无需重启服务

✅ 完整的编程能力（循环、条件、变量等）

✅ 执行性能优化，满足高频审核场景

2.“大对象”抽象——让规则理解 SQL 的完整语义

DBdoctor 将 SQL 的完整信息抽象为大对象（Big Object），自定义规则可以访问到：

（1）SQL 语法树（AST）解析信息

// 获取 SQL 中所有涉及的表data.tableMap// 检查是否包含 JOIN 操作data.hasJoin// 查看 WHERE 条件中的字段data.whereColumns

（2）实时元数据信息

// 检查表“users”中“email”字段的类型data.dbMetaInfo.dbTableInfoMap["users"].allColumnMap["email"].type// 验证索引是否存在data.dbMetaInfo.dbTableInfoMap["orders"].indexList

（3）执行计划深度分析

// SQL Server 中检测全表扫描for planInfo in data.planInfoList {    if (string.contains(planInfo.PhysicalOp, "Table Scan")) {        return createRuleCheckInfo(true, "存在全表扫描风险");    }}// MySQL 中检查索引使用情况if (data.planInfo.extraInfo.indexOf("Using filesort") > -1) {    return createRuleCheckInfo(true, "存在文件排序，性能可能受影响");}

第二步：配置规则基本信息

• 规则标题：清晰描述规则目的，如“禁止创建 money 字段”

• 规则描述：详细说明规则背景和检查项

• 严重等级：根据业务影响选择（致命/高/中/低）

• 是否拦截：决定是否阻止 SQL 执行

• 适用引擎：选择规则生效的数据库类型

第三步：编写规则逻辑表达式

基于大对象提供的丰富信息，编写判断逻辑：

//变量语法树，获取新增列是否有列名为name的，若存在则命中该规则for tbName in seq.keys(data.tableMap) {  let tableValues = data.tableMap[tbName];  if is_empty(tableValues.addColumnList) {    return createRuleCheckInfo(false, "");  }  for col in seq(tableValues.addColumnList) {    if(col.name == "money") {          return createRuleCheckInfo(true, ruleDesc);        }  }}return  createRuleCheckInfo(false, "");

对上面的自定义规则进行场景测试验证

1.在测试窗口中输入样例 SQL 进行验证

提交审核sql：

create table test_table (  id int,  money int)

2.查看规则命中情况和提示信息

我们可以在审核结果中可以看到，新增的sql审核命中并且给予提示，并查看具体审核详情。

// 规则：订单表必须包含订单状态索引if (data.tableMap["orders"] != null) {    let hasStatusIndex = false;    if (data.dbMetaInfo.dbTableInfoMap["orders"].allColumnMap["order_status"] != nil) {      hasStatusIndex = true;    }    if (!hasStatusIndex) {        return createRuleCheckInfo(true, "订单表必须创建 order_status 字段索引");    }}

场景二：数据隔离安全要求

// 规则：多租户系统查询必须包含 tenant_id 条件if (data.sqlType == "query" && data.tableMap["user_data"] != null) {    let whereCondition = data.whereSql;    if (whereCondition.indexOf("tenant_id") == -1) {        return createRuleCheckInfo(true, "查询用户数据必须指定租户条件");    }}

场景三：性能红线保障

// 规则：查询预估扫描行数超过 100 万需告警if (data.planInfo.estimatedRows > 1000000) {    return createRuleCheckInfo(true, `查询扫描行数预估 ${data.planInfo.estimatedRows}，超过性能红线`);}