告别“一刀切”，让 SQL 审核真正懂业务，DBdoctor 自定义SQL审核详解

原创于 2026-02-12 10:46:23 发布 · 725 阅读

10 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#sql #java #数据库 #dbdoctor #mysql

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

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

金融行业可能严格要求所有交易表必须包含审计字段
电商系统可能禁止在高峰期执行特定类型的 DDL
数据平台可能要求所有查询必须包含租户隔离条件
团队内部规范如强制使用语义化别名、禁止某些函数等

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

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

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

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

核心特性

灵活适配：从语法级到语义级，从表结构到执行计划，全方位自定义
简单易用：可视化配置结合脚本编写，技术人员快速上手
实时生效：规则热更新，无需等待产品迭代，即时响应业务变化
多引擎统一：一套自定义体系覆盖 MySQL、PostgreSQL、SQL Server 等多数据库

三、技术实现：如何让 SQL 审核“智能”起来？

1.动态编译引擎——规则的可编程基础

DBdoctor 没有采用传统的 if-else 硬编码方式，而是内置了动态编译表达式引擎，允许用户编写灵活的逻辑判断：

// 业务场景：金融系统要求所有表必须包含创建时间、更新时间字段
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, "存在文件排序，性能可能受影响");
}

四、实战操作：三步完成业务规则定制

第一步：进入规则管理界面

以超级管理员身份登录 DBdoctor，进入【SQL 审核管理】→【规则审核管理】→【自定义规则】，点击“新建规则”。

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

规则标题：清晰描述规则目的，如“禁止创建 money 字段”
规则描述：详细说明规则背景和检查项
严重等级：根据业务影响选择（致命/高/中/低）
是否拦截：决定是否阻止 SQL 执行
适用引擎：选择规则生效的数据库类型

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

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

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}，超过性能红线`);
}

六、效果对比：从“标准化”到“个性化”

维度	传统内置规则	DBdoctor 自定义规则
适应性	通用最佳实践，一刀切	贴合具体业务场景
响应速度	等待产品版本迭代	即时创建，实时生效
覆盖深度	语法层面检查	语法 + 语义 + 执行计划+...
维护成本	厂商主导，用户被动接受	团队自主维护，持续演进
业务价值	规避基础风险	直接支撑业务规范与合规要求