企业官网建设流程全解析

直接讲结论：这年头如果报表查询还在写死 SQL、一个条件一个 if 堆到天荒地老，那基本等于给自己埋雷。标题里说的“动态 SQL”和“规则引擎”，拆开看都不算新东西，但组合起来解决报表灵活查询这件事，确实是一条值得落地的路子。我最近在一个模拟项目X里把这套方案完整跑通了，从接口设计到规则配置再到查询引擎，踩了不少坑，也总结出一套可以“抄作业”的流程，这篇就把核心思路、实操步骤和避坑经验一次说清楚。

1. 为什么“告别硬编码”不是矫情，是刚需

1.1 报表查询的本质矛盾：业务要变，代码不能天天改

做过报表需求的人应该都有同感：业务方提需求的时候永远是一句话的事——“这个报表加个筛选条件”“这里按部门汇总一下”。但你打开代码一看，好家伙，一个查询方法里塞了十几个 if 判断，每个 if 后面跟一段拼接的 SQL，稍微加点逻辑整个方法就膨胀到几百行。更要命的是，这种代码改一次就要重新编译、重新部署、重新测试，一个报表从提需求到上线，快则一两天，慢则一周起步，业务等不起，开发也扛不住。

我参与的那个模拟项目X就是这样。起初报表查询逻辑还算简单，固定几个条件、固定几张表，直接写 SQL 就能满足。但运行了半年之后，需求开始“失控”：同样的订单数据，今天要按区域筛，明天要按客户等级筛，后天又要加一个“销售额环比增长超过20%”的过滤条件。这些需求单看都不复杂，但叠加起来，查询方法的复杂度呈指数增长，代码里全是 if else 嵌套，同事接手的时候看注释的时间比写代码的时间都长。

硬编码最坑的不是“写起来麻烦”，而是“改起来要命”。每改一次报表逻辑，你都得完整走一遍“改代码 — 重启服务 — 验证数据”的老三样流程，而业务方永远觉得这不应该这么慢。说实话，在一个报表需求每周都变的系统里，硬编码方案注定走不远。

1.2 动态 SQL + 规则引擎这套组合拳打的是什么痛点

先说动态 SQL。很多人一听到“动态 SQL”就以为是 MyBatis 里那种<if><where>标签拼接，这确实是动态 SQL 的一种形态，但只是“查询条件动态化”，还谈不上“查询逻辑动态化”。真正的报表灵活查询，需要的是组合条件的动态化：用户在前端勾选几个筛选条件、选择一种汇总维度、指定一种排序规则，后端能自动拼出对应的查询语句，整个过程不写一行 Java 代码、不改一次已部署的服务。

再说规则引擎。规则引擎这个词听起来很重，但放到报表场景里，它其实干的就是一件事：把“查询怎么组织”的决策逻辑从代码里挪到配置里。以前“哪些条件可以组合”“条件之间是 AND 还是 OR”“哪些字段参与汇总”这些规则都是写死在 Java 方法里的，现在把它们抽出来，变成一条条可配置的规则，存储在数据库或者配置中心里，后端有一个引擎负责加载规则、解析规则、执行规则。

这两个东西单独拿出来，动态 SQL 只是工具，规则引擎只是框架。但组合起来效果就出来了：动态 SQL 负责“怎么拼”，规则引擎负责“拼什么”。前端传过来一个查询请求，规则引擎根据预设规则判断这次查询需要哪些条件、哪些维度、哪些汇总方式，然后动态 SQL 把这一切翻译成数据库能执行的语句。业务方想加一个新的查询维度？不用找开发改代码，运维或者实施人员在规则配置页面上加一条规则就够了。

1.3 这套方案适合谁、不适合谁

先说适合的。如果你的项目满足以下特征，建议认真考虑这套方案：

• 报表查询条件频繁变化，每周甚至每天都有新的筛选需求
• 报表使用方是业务人员、运营人员，他们需要自己调整查询维度，而不是每次都发工单给开发
• 系统里有多种角色需要看不同粒度的数据，同一份数据要按不同维度切分
• 项目组人力有限，没精力为每个报表单独维护一套查询接口

反过来，如果项目就一张报表、三个固定条件、半年不变一次，那你用硬编码写 SQL 反而是最省事的选择。引入规则引擎某种程度上是“过度设计”，因为规则引擎本身有学习成本，配置规则也需要一段时间磨合。另外，查询性能要求极高、SQL 语句必须由 DBA 手动调优的场景，也不适合完全交给规则引擎自动拼 SQL——那种场景更适合把核心查询固化成存储过程或者视图。

2. 核心设计思路：先想清楚“规则”控制什么

2.1 建立规则模型：把查询语义拆成可配置的原子单元

动手写代码之前，最重要的不是选框架，而是把规则模型设计好。我见过不少项目，规则引擎选型没问题，动态 SQL 的技术栈也没问题，但最终做出来还是一锅粥，原因就是规则模型没设计清楚——规则到底管哪一层？粒度是粗还是细？边界在哪里？

我自己在设计的时候，把报表查询拆成了四个层级：

第一层是查询条件层，定义哪些字段可以作为筛选条件，例如“时间范围”“区域”“客户等级”“产品分类”，每个条件包含字段名、操作符（等于、不等于、大于、包含、区间）、对应的前端参数名。

第二层是维度组合层，定义哪些字段可以自由组合作为分组维度，例如“按区域 + 按客户等级”可以一起分组，“按产品分类 + 按月”可以一起分组。这里的关键是校验组合合法性——不是所有字段都能随意组合的，字段和字段之间可能存在语义冲突。

第三层是汇总计算层，定义指标怎么算，例如“销售额求和”“订单量计数”“客单价求平均”“同比增长率计算公式”。这个层级往往是最容易被忽略的，很多人以为报表只是“查出来就完了”，实际上更多的需求是“查出来之后怎么算”。

第四层是结果排序层，定义结果集按什么字段、升序还是降序排列，支持多级排序。

规则引擎管的就是这四个层级的“决策逻辑”。前端传过来一个查询请求，规则引擎先判断这个请求里涉及哪些查询条件，再判断这些条件允许怎么组合，然后决定查询的维度、指标、排序方式，最后把这些决策结果交给动态 SQL 执行器去拼 SQL、查数据库。

这样设计的核心价值在于，每一个规则都是“原子”的，单独修改一条规则不会影响其他规则。比如“客户等级”这个字段原来只支持“等于”操作，需求变更后想支持“包含多个等级”，你只需要修改这一条规则，而不需要动任何查询逻辑代码。

2.2 规则存储方案：数据库配置表为主，配置中心为辅

规则存哪儿？这是另一个容易踩坑的地方。有人前面做得挺好，到存储这块脑子一热全塞进代码里，结果还是没绕开“改配置要重新部署”的魔咒。我建议的存储方案是：核心规则放数据库配置表，运行参数放配置中心。

数据库配置表适合放那些需要业务人员频繁调整的规则，例如：

• 每个查询字段的操作符类型
• 字段组合校验规则
• 汇总指标的计算表达式
• 默认排序规则

配置中心适合放那些技术属性更强的规则，例如：

• 某些大表查询的超时时间
• 动态 SQL 的缓存开关
• 规则引擎的并发策略

为什么这么分？因为业务人员能接触到的是报表配置页面，他们需要的是“改完了立刻生效”，数据库配置表改一条记录就能做到这一点；而技术属性规则基本只有开发和运维人员会碰，放在配置中心里便于统一管理，也能避免业务人员误操作。

实际存储结构上，我用了三张核心表：

• 规则定义表：存规则的基础信息，比如规则编码、规则名称、规则类型、生效状态
• 规则条件表：存规则里面的条件项，比如一个规则里面包含了哪个字段、用了什么操作符、参数值从哪里取
• 规则动作表：存规则命中之后的动作，比如“追加查询条件”“切换分组维度”“应用计算公式”

三张表的设计思路是让规则可以自由组合，一条规则可以有多个条件、多个动作，条件之间支持 AND/OR 逻辑。这样设计之后的规则引擎，本质上就是一个“条件 → 动作”的匹配器，只不过匹配的深度和复杂度比普通规则引擎要轻量得多。

2.3 技术选型：为什么选了“轻量自研”而不是重型框架

技术选型上，我对比过几个方案。重型规则引擎像 Drools，功能确实强大，支持复杂的规则流、决策表、Rete 算法，但问题是学习成本高、部署复杂、调试困难。一个报表查询场景，规则粒度也就是“字段 A 等于 xxx 且字段 B 大于 xxx”，这种匹配逻辑用重型规则引擎属于高射炮打蚊子，杀鸡用牛刀不说，团队成员还得专门培训。

动态 SQL 这块，我一开始也纠结过要不要直接用 MyBatis 的<if>标签写动态 SQL。后来发现这有个问题：MyBatis 的动态 SQL 是“代码编译期”的，也就是写死了的条件模板，它支持你根据参数动态决定要不要拼某个片段，但“动态”的范围取决于你在 mapper XML 里写了多少个<if>。真正的问题是，你永远不知道业务方明天会提什么新条件，这意味着你的 mapper 文件要没完没了地加<if>，本质上还是没跳出“改代码”的圈子。

最终我的选择是：规则引擎部分自研一个轻量级引擎，动态 SQL 部分建立一个简单的条件解析器和 SQL 组装器，不依赖 MyBatis 的动态标签，而是在 Java 层面生成 SQL 片段。

自研轻量引擎的原因很简单：报表查询场景的规则就那几种类型，条件匹配、维度组合、指标计算、结果排序，四种类型每种都用简单的表驱动方式实现，代码量可控，逻辑透明，团队成员都能看懂、能维护。重型框架虽然功能多，但大部分功能你用不上，还得为用不上的功能付学习成本和部署成本。

SQL 组装器这块，核心思路是“结构化拼接”。我定义了一个查询模型，包含 select 字段、from 表、join 条件、where 条件、group by 字段、order by 字段、limit 值，然后提供一系列方法往模型里追加内容。规则引擎决策出来的每一个“动作”，本质上就是往这个模型里追加一段内容。等规则全部执行完，SQL 组装器再把模型翻译成最终的 SQL 语句。

这套方案的优势是完全可控，每个环节都能打印日志、能断点调试、能单测覆盖，出了问题排查链路清晰。不像重型框架，一个问题查半天还不知道是规则写错了还是引擎 bug。

3. 实操过程：从零搭建一套可用的灵活报表查询服务

3.1 环境准备与工程结构

先交代一下模拟项目X的基础环境：

• 技术栈：Spring Boot 2.7.x，JDK 1.8，MyBatis-Plus 3.5.x，MySQL 8.0
• 依赖管理：Maven
• 缓存：Caffeine 本地缓存

工程结构上，我按“规则引擎”和“动态 SQL”两条主线路分了包，再加上通用的查询入口层：

com.example.report ├── controller # 报表查询接口层 ├── engine # 规则引擎核心 │ ├── model # 规则模型（规则定义、条件、动作） │ ├── loader # 规则加载器（从数据库加载规则） │ ├── matcher # 规则匹配器（判断请求是否命中规则） │ └── executor # 规则执行器（执行规则动作） ├── query # 动态 SQL 查询引擎 │ ├── model # 查询模型（SelectModel、WhereCondition） │ ├── builder # SQL 组装器 │ ├── parser # 请求参数解析器 │ └── executor # 查询执行器 ├── config # 配置中心读取、缓存配置 └── common # 通用返回结构、异常处理

这个结构的好处是规则引擎和动态 SQL 引擎完全解耦。规则引擎产出的是“查询模型”级别的中间结果，不关心 SQL 怎么写；动态 SQL 引擎接收的是结构化的查询模型，不关心规则怎么来的。两者之间只有一个数据交换的接口，这就是它们能独立演进的基础。

3.2 规则加载与缓存：避免每次请求都查配置表

规则引擎第一步是加载规则。规则存在数据库配置表里，如果你的引擎每次都实时查配置表，性能上肯定扛不住。我做了一层 Caffeine 本地缓存，规则加载策略是“启动时全量加载 + 定时刷新 + 手动失效”。

启动时全量加载的优点是实现简单，应用启动时把规则定义表、条件表、动作表全部查出来，组装成内存里的规则对象。之后请求打过来，直接从缓存拿规则，不再查库，性能非常好。缺点也有，就是规则改了之后最迟要等刷新周期才能生效，所以我添加了一个“手动触发刷新”的接口，配置人员在界面上保存规则之后，后台自动调一次刷新接口，让规则立即生效。

规则加载代码大致长这样：

@Service public class RuleLoader { private final RuleMapper ruleMapper; private final RuleConditionMapper conditionMapper; private final RuleActionMapper actionMapper; private final Cache<String, List<ReportRule>> ruleCache; public RuleLoader(RuleMapper ruleMapper, RuleConditionMapper conditionMapper, RuleActionMapper actionMapper) { this.ruleMapper = ruleMapper; this.conditionMapper = conditionMapper; this.actionMapper = actionMapper; this.ruleCache = Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(10, TimeUnit.MINUTES) .build(); } public List<ReportRule> loadRules(String bizCode) { return ruleCache.get(bizCode, key -> { List<RuleDefinition> definitions = ruleMapper.selectByBizCode(key); List<ReportRule> rules = new ArrayList<>(); for (RuleDefinition def : definitions) { ReportRule rule = new ReportRule(); rule.setRuleCode(def.getRuleCode()); rule.setRuleName(def.getRuleName()); rule.setEnabled(def.getEnabled()); rule.setConditions(conditionMapper.selectByRuleCode(def.getRuleCode())); rule.setActions(actionMapper.selectByRuleCode(def.getRuleCode())); rules.add(rule); } return rules; }); } public void refresh(String bizCode) { ruleCache.invalidate(bizCode); loadRules(bizCode); } }

这段代码里有几个细节值得注意。第一，缓存 key 用 bizCode 而不是直接把所有规则放进一个缓存，这样不同业务模块的规则隔离，互不影响。第二，expireAfterWrite 设置为 10 分钟，是一种兜底策略，即使手动刷新接口没调成功，10 分钟之后缓存也会自动过期重新加载。第三，加载规则的时候把条件表和动作表一次性查出来组装好，避免后面执行的时候再一级级查库。

3.3 规则匹配执行：从请求参数到查询模型

规则加载到内存之后，下一步就是匹配和执行。这一步是整个规则引擎的“主流程”，我的实现方式是：

1. 接收前端查询请求
2. 解析请求参数，提取查询条件、分组维度、汇总指标
3. 根据 bizCode 加载规则列表
4. 逐条规则判断是否命中当前请求
5. 命中规则的 action 依次执行，填充查询模型
6. 查询模型转 SQL，执行查询

步骤 4 是核心。每条规则包含若干条件，条件的形式是“左值 + 操作符 + 右值”。左值可以是请求参数里的字段名，右值可以是常量。例如一条规则的条件是“request.source = 'mobile'”，意思是当请求来源为移动端时命中。多条条件之间支持 AND 和 OR 逻辑，我加了一个 conditionRelation 字段来标记。

规则匹配代码节选：

public boolean match(ReportRule rule, QueryRequest request) { String relation = rule.getConditionRelation(); // "AND" or "OR" List<RuleCondition> conditions = rule.getConditions(); if (conditions.isEmpty()) { return true; } if ("OR".equalsIgnoreCase(relation)) { for (RuleCondition condition : conditions) { if (matchSingle(condition, request)) { return true; } } return false; } else { for (RuleCondition condition : conditions) { if (!matchSingle(condition, request)) { return false; } } return true; } } private boolean matchSingle(RuleCondition condition, QueryRequest request) { Object actualValue = request.getParam(condition.getRequestField()); if (actualValue == null) { return false; } switch (condition.getOperator()) { case "eq": return actualValue.toString().equals(condition.getExpectedValue()); case "neq": return !actualValue.toString().equals(condition.getExpectedValue()); case "contains": return actualValue.toString().contains(condition.getExpectedValue()); default: return false; } }

规则命中之后的动作执行，是这个引擎里最有意思的部分。不同的动作类型对应不同的查询模型修改策略：

• 动作类型“ADD_CONDITION”：往查询模型的 where 条件里追加一个查询条件
• 动作类型“ADD_GROUP_BY”：往查询模型的 group by 里追加一个分组字段
• 动作类型“SET_METRIC”：设置查询模型的指标计算表达式
• 动作类型“SET_ORDER_BY”：设置查询模型的排序规则

这些动作的类型是配置在数据库里的，也就是说，你新增一种动作不需要重新发布应用，只需要在配置表里加一条记录，然后引擎的 action executor 里如果已经支持这种动作类型，就能直接生效。

3.4 动态 SQL 组装器：把查询模型翻译成 SQL

规则引擎执行完，我们拿到的是一个结构化的查询模型。接下来就是动态 SQL 组装器的工作：把这个模型转换为合法的 SQL 语句。

先看查询模型的定义：

public class QueryModel { private List<String> selectFields = new ArrayList<>(); private String mainTable; private List<JoinInfo> joins = new ArrayList<>(); private List<QueryCondition> whereConditions = new ArrayList<>(); private List<String> groupByFields = new ArrayList<>(); private List<QueryMetric> metrics = new ArrayList<>(); private List<OrderByField> orderByFields = new ArrayList<>(); private int limit = 1000; }

组装器的工作流是：

1. 先拼接 SELECT 字段：把分组字段和指标字段都放进去
2. 拼接 FROM 主表
3. 拼接 JOIN 子句（如果需要关联查询）
4. 拼接 WHERE 子句：遍历 whereConditions，根据条件之间的关系（AND/OR）加连接符
5. 拼接 GROUP BY
6. 拼接 ORDER BY
7. 拼接 LIMIT

最核心的是 WHERE 子句的拼接，因为这里涉及操作符的转换和参数的安全处理。我遇到过不少人直接拼字符串导致 SQL 注入，所以这里必须用预编译的占位符。

public String buildSql(QueryModel model, List<Object> params) { StringBuilder sql = new StringBuilder(); sql.append("SELECT "); // 拼接 select 字段 for (String field : model.getSelectFields()) { sql.append(field).append(", "); } for (QueryMetric metric : model.getMetrics()) { sql.append(metric.getExpression()).append(" AS ").append(metric.getAlias()).append(", "); } sql.setLength(sql.length() - 2); // 拼接 from 和 join sql.append(" FROM ").append(model.getMainTable()); for (JoinInfo join : model.getJoins()) { sql.append(" ").append(join.getType()).append(" JOIN ") .append(join.getTable()).append(" ON ").append(join.getOnClause()); } // 拼接 where if (!model.getWhereConditions().isEmpty()) { sql.append(" WHERE "); List<QueryCondition> conditions = model.getWhereConditions(); sql.append(buildWhereClause(conditions, params)); } // 拼接 group by if (!model.getGroupByFields().isEmpty()) { sql.append(" GROUP BY "); sql.append(String.join(", ", model.getGroupByFields())); } // 拼接 order by if (!model.getOrderByFields().isEmpty()) { sql.append(" ORDER BY "); for (int i = 0; i < model.getOrderByFields().size(); i++) { if (i > 0) sql.append(", "); OrderByField field = model.getOrderByFields().get(i); sql.append(field.getField()).append(" ").append(field.getDirection()); } } // 拼接 limit sql.append(" LIMIT ?"); params.add(model.getLimit()); return sql.toString(); }

注意这里的参数处理方式。我没有把查询条件的值直接拼到 SQL 字符串里，而是把条件值放进 params 列表，SQL 里用占位符代替。最终执行的时候，用 PreparedStatement 来绑定参数。这是防止 SQL 注入的关键，绝不能省。

3.5 查询执行与结果返回：别忽略分页和数据量控制

查询模型组装好、SQL 生成好，最后一步就是用 MyBatis-Plus 或者 JDBC 执行查询并返回结果。这里有几个细节容易被忽视。

第一个是数据量控制。报表查询不像普通业务查询，一个报表查出来几万行甚至十几万行都很正常。但也不能让查询无限制地跑，所以我给查询模型设置了默认 limit 1000，前端可以在请求参数里覆盖这个值，但最高只能调到 5000。这样既保证了业务方一次能拿到足够的数据，又避免了一眼看不到头的全表扫描。

第二个是超时控制。为了不让一条慢 SQL 把整个服务拖垮，我加了一个查询超时机制。Spring 的 @Transactional 里可以用timeout属性，但报表查询往往不需要事务，我直接通过 JDBC 层的setQueryTimeout来控制：

@Autowired private JdbcTemplate jdbcTemplate; public List<Map<String, Object>> executeQuery(String sql, List<Object> params, int timeoutSeconds) { return jdbcTemplate.query(connection -> { PreparedStatement ps = connection.prepareStatement(sql); ps.setQueryTimeout(timeoutSeconds); int index = 1; for (Object param : params) { ps.setObject(index++, param); } return ps; }, (rs, rowNum) -> { ResultSetMetaData metaData = rs.getMetaData(); Map<String, Object> row = new HashMap<>(); for (int i = 1; i <= metaData.getColumnCount(); i++) { row.put(metaData.getColumnLabel(i), rs.getObject(i)); } return row; }); }

之前线上遇到过一次问题：某个业务方在报表里加了三个大表的笛卡尔积关联，一条查询跑了 40 多秒，把所有数据库连接都占满了，导致其他正常业务也受影响。加了超时控制之后，超过 15 秒的查询会被强制中断，并且返回一个“查询超时，请简化筛选条件”的提示，这个体验问题直接解决了。

第三个是空值兼容。报表查询里，用户可能传空字符串、传 null、传不存在的字段名。这些情况必须在解析层就拦下来，不能让他们跑到 SQL 层。我在请求参数解析器里做了一层白名单校验：字段名必须存在于字段字典表里，否则直接报参数错误；空字符串当作 null 处理；操作符也必须限定在允许的范围内。

4. 常见问题与排查技巧实录

4.1 规则命中但结果不对：先查规则条件的“作用域”

这是我在模拟项目X里踩得最多的坑。一条规则配好之后，看起来命中了，但查询结果却不符合预期，SQL 里多了一段不该出现的条件，或者少了一段应该出现的条件。

排查思路分两步。第一步，先确认规则是不是真的被加载了——很多次是缓存没刷新，规则已经改了，但内存里还是旧版本。第二步，确认规则的 action 执行顺序——多条规则的 action 都往查询模型里追加内容，如果顺序不对，后面的 action 可能覆盖了前面的 action。

给我的教训是：规则配置页面一定要展示规则的执行顺序，并且在保存时做一次模拟执行，把“请求参数 → 命中规则 → 生成的查询模型 → 生成的 SQL”完整展示出来。这样配置人员能直观看到这条规则的变更产生了什么影响，而不是等查询结果不对才回头排查。

4.2 SQL 拼接乱套：where 和 having 分不清

报表查询里经常有这种需求：“只显示销售额大于 10000 的分组”。熟悉 SQL 的人知道，分组前的过滤用 WHERE，分组后的过滤用 HAVING。但业务方不懂这个，他们只会说“我要过滤销售额大于 10000 的”，然后就把这个条件配置上去了。

如果你把分组后的过滤条件错误地放进了 WHERE 子句，要么 SQL 语法报错，要么结果完全不对。我的做法是在查询模型里加了一个 conditionType 字段，区分“这个条件是先过滤还是后过滤”。在规则配置的动作里，配置人员需要选择过滤时机；在实际执行时，组装器会根据 conditionType 决定把条件放 WHERE 还是 HAVING。

还有一个容易踩的坑是 GROUP BY 字段没进 SELECT 列表。MySQL 5.7 及以下版本只开ONLY_FULL_GROUP_BY的话，SQL 直接报错。我这里的经验是组装器在拼接 SELECT 字段时，自动把 GROUP BY 字段也加到 SELECT 列表里去，避免配置人员漏配造成查询失败。

4.3 前端参数和规则字段名对不上：别让配置人员猜

规则引擎灵活性的前提是配置简单。如果你的配置人员要记着一长串英文字段名，配置效率直接减半。我的做法是建立一套“字段字典”，每个字段有一个业务名称和一个技术字段名，配置人员在配置页面里通过下拉选择业务名称，系统自动映射技术字段名。

请求参数解析器也是基于这套字段字典做的。前端传入的参数是技术字段名，解析器校验参数是否存在于字典中，不存在的直接忽略或者报错。这个设计极大地减少了配置出错的概率。

4.4 性能优化：缓存查询结果到底行不行

规则引擎 + 动态 SQL 这套方案，性能上最大的瓶颈在“每次请求都要走一遍规则解析和 SQL 组装”。这个流程本身开销不大，但如果报表的数据量大， SQL 执行性能才是真正的问题。

有人会想到缓存查询结果。我的观点是：报表查询结果缓存要非常谨慎。因为报表数据通常是实时变动的，缓存时间稍长，业务方就会质疑数据的准确性。我最后只在“汇总统计型报表”上做了缓存，缓存时间 30 秒，而且只在数据源明确不频繁变动的情况下才开启。明细型报表一律不缓存，保证每次查询都是实时数据。

对于大表查询，我更推荐的是物化视图或者汇总表方案。把高频查询的统计结果预先计算好放进一张汇总表，查询的时候直接查汇总表，性能比每次实时聚合高一个数量级。规则引擎在这套方案里依然有用——它就负责决定“这次查询应该查明细表还是汇总表”，以及“如果查汇总表，按什么维度从汇总表里取数”。

还有一个性能优化点是索引。动态 SQL 的查询条件是不固定的，你没法为每个可能出现的条件组合都建索引。我的经验是：针对高频查询条件组合建复合索引，低频条件组合不强求索引，让数据库走全表扫描，但通过 limit 限制数据量来控制开销。高频条件组合可以通过报表访问日志统计出来，定期调整索引策略。

4.5 配置错误排查速查表

5. 实操心得：这套方案后续还能怎么扩展

项目上线之后，我把这套方案扩展了几个方向，效果都不错，供你参考。

第一个扩展是“报表模板”的概念。规则引擎的规则组合本质上是报表的“配方”，我们后来把一套规则组合封装成一个“报表模板”，业务方在前端选择某个报表模板，系统自动应用模板里绑定的规则集合，然后用户在模板基础上再叠加临时筛选条件。这样既保证了常用报表的口径统一，又给了用户一定的灵活性。

第二个扩展是“规则版本管理”。规则在数据库里配置，难免会遇到“改坏了想回滚”的情况。我给规则表加了一个 version 字段，保存规则时保留历史版本，支持一键回滚到任意历史版本。这个功能实现成本很低，但业务方非常喜欢，因为感觉自己对规则有了完全的控制权，不怕改错。

第三个扩展是“查询链路日志”。我把“请求参数 → 命中规则 → 查询模型 → SQL 语句 → 查询耗时”整条链路都打成结构化日志，存到独立的日志表里。业务方反馈“报表数据不对”的时候，我直接查日志就能还原出他当时到底查了什么、规则生成了什么 SQL、结果为什么和预期不符。这个能力在排查问题上帮了大忙，强烈建议你也加上。

最后说说我对这套方案的总体评价。轻量级规则引擎 + 动态 SQL 组装器，解决的是“业务方需要灵活调整报表查询，但开发不想被没完没了的修改需求拖死”的矛盾。它不能替代 DBA 做 SQL 调优，也不能替代大数据平台做海量数据分析，但在传统企业级应用的单库查询场景里，它是一套非常实用、投入产出比很高的方案。只要你把规则模型设计清楚，把字段字典维护好，这套东西可以稳定运行很久，而且每加一种查询能力，都只是加一条规则的功夫。