ABAP RFC SQL 模糊查询与动态区间条件实战解析

关注

原创最新推荐文章于 2026-10-05 13:05:11 发布 657 阅读 AI 写同款· GEO 优化 ›

关于 ABAP OPEN SQL 的动态 WHERE 条件和 Dynamic Selections ABAP动态查询技术解析本文介绍了ABAP中实现灵活数据库查询的动态选择技术，通过FREE_SELECTIONS函数组实现用户自定义查询条件。核心内容包括：传统固定WHERE条件的局限性，无法满足业务多变需求 Dynamic Selections机制的工作原理，使用FREE_SELECTIONS_INIT初始化、FREE_SELECTIONS_DIALOG交互完整Demo程序演示如何构建通用表数据浏览器：用户输入表名后校验权限调用动态选择函数生成条件动态拼接WHERE子句执行查询使用CL_SA 阅读详情

1. 为什么RFC接口的查询条件不能太“死板”？

大家好，我是老韩，在SAP和外围系统集成的坑里摸爬滚打了十几年。今天想和大家聊聊一个看似基础，但实际开发中几乎每个接口都会遇到的“老大难”问题：在ABAP RFC接口里，如何优雅地处理用户五花八门的查询条件？

想象一下这个场景：你写了一个RFC函数ZSAP_GET_SALES_ORDER，用来给外围的.NET或Java系统提供销售订单查询服务。接口里定义了一堆输入参数，比如订单号、客户编号、创建日期范围、金额范围等等。理想很丰满，用户在前端界面输入精确的条件，你后端直接拼接到WHERE子句里，完美。

但现实很骨感。用户可能只想查“包含‘ABC’的所有订单”，给你传个ABC；也可能只想查“2024年9月之后的订单”，只填一个开始日期；甚至可能啥也不填，就想看看最近的所有数据。如果你的SQL语句还是傻乎乎地写WHERE VBELN = @IV_VBELN，那用户输入空值或者模糊值的时候，要么查不到数据，要么就报错。

所以，一个健壮的RFC接口，其查询逻辑必须足够“聪明”和“灵活”。核心就在于两点：对字符串字段支持模糊匹配，以及对区间字段（日期、数字）支持动态的、容错的范围处理。这不仅仅是提升用户体验，更是减少前后端扯皮、降低运维成本的关键。今天，我就结合一个真实的案例，把这块的实战经验掰开揉碎了讲给你听。

2. 字符串模糊查询：一招鲜，吃遍天

我们先从最简单的字符串模糊查询说起。在ABAP Open SQL中，实现模糊查询的语法是LIKE搭配通配符%（代表任意多个字符）和_（代表单个字符）。这和其他数据库（如MySQL、SQL Server）是类似的。

2.1 基础操作：如何拼接出模糊查询条件

假设我们有一个物料描述MAKTX字段需要支持模糊查询。用户传入了参数IV_MAKTX。最直接的做法就是在ABAP代码里，给参数前后加上%。

DATA: lv_maktx_pattern TYPE string.

IF iv_maktx IS NOT INITIAL.
  CONCATENATE '%' iv_maktx '%' INTO lv_maktx_pattern.
ENDIF.

SELECT * FROM makt
  INTO TABLE @DATA(lt_makt)
  WHERE spras = @sy-langu
    AND maktx LIKE @lv_maktx_pattern.

这段代码的逻辑很清晰：如果用户输入了内容，就构造一个前后带%的模式串，然后用于LIKE查询。如果用户没输入（INITIAL），理论上我们应该跳过这个条件，否则LIKE '%%'会匹配所有行，虽然语法正确，但可能带来不必要的性能开销。更常见的做法是，在构建动态WHERE条件时，如果查询字段为空，就直接不添加该条件。

但是，这里有一个新手非常容易踩的坑！ 你可能会想，我直接在传入的参数上拼接%行不行？比如：

CONCATENATE '%' iv_maktx '%' INTO iv_maktx. " 错误示范！"

这是绝对错误的！ 这会直接修改导入参数IV_MAKTX的值，破坏了参数的原始数据，如果后续还有其他逻辑要用到这个参数，就会出错。所以，务必使用一个本地变量（如lv_maktx_pattern）来接收拼接后的结果。

2.2 实战优化：处理多个模糊查询字段

在一个实际的RFC接口中，往往有多个字段需要支持模糊查询。像原始文章例子里的ZTYPE（类型）、ZSPNUMBER（单号）、VIN（车架号）等等。如果每个字段都写一遍IF...CONCATENATE...，代码会显得非常冗余。

我们可以采用一种更简洁的批量处理方式。虽然ABAP没有特别优雅的语法糖，但我们可以利用循环和动态赋值的思想来让代码更整洁。不过，为了清晰和可维护性，像原始文章那样显式地处理每一个字段，反而是更推荐的做法，尤其是字段数量不多的时候。代码一目了然，方便后续维护者理解。

* 假设所有需要模糊查询的字段都是STRING类型
DATA: lv_ztype_pattern TYPE string,
      lv_zspnumber_pattern TYPE string,
      lv_vin_pattern TYPE string.

* 为每个非空的输入参数构造模糊查询模式
IF ztype IS NOT INITIAL.
  CONCATENATE '%' ztype '%' INTO lv_ztype_pattern.
ELSE.
  lv_ztype_pattern = '%'. " 或者后续在WHERE中跳过该条件
ENDIF.

IF zspnumber IS NOT INITIAL.
  CONCATENATE '%' zspnumber '%' INTO lv_zspnumber_pattern.
ELSE.
  lv_zspnumber_pattern = '%'.
ENDIF.

IF vin IS NOT INITIAL.
  CONCATENATE '%' vin '%' INTO lv_vin_pattern.
ELSE.
  lv_vin_pattern = '%'.
ENDIF.

SELECT * FROM ztable
  INTO TABLE @ot_list
  WHERE ztype LIKE @lv_ztype_pattern
    AND zspnumber LIKE @lv_zspnumber_pattern
    AND vin LIKE @lv_vin_pattern.
    " ... 其他条件

这里有个小技巧：当输入参数为空时，我们将模式串设为%。这样LIKE '%'会匹配该字段的所有值，在逻辑上等同于“忽略此过滤条件”。这是一种简单的实现方式。但在性能敏感的查询中，特别是表数据量很大时，过多的LIKE '%'条件可能会对优化器造成干扰。更优的方案是使用动态WHERE子句，只在参数非空时才添加相应的LIKE条件。

3. 动态区间条件处理：日期与数字的“智能”适配

比起模糊查询，区间条件（BETWEEN ... AND ...）的处理更需要“智能”。因为用户输入的可能性更多样：可能不填、可能只填开始值、可能只填结束值、也可能都填。我们的程序需要自动适配所有这些情况，构造出一个合法的、有意义的BETWEEN条件。

3.1 日期区间处理的三种场景与代码实现

日期区间是业务查询中最常见的。我们假设有两个输入参数：IV_DATE_FROM和IV_DATE_TO，类型是CHAR8（格式YYYYMMDD）。下面是必须处理的三种情况：

场景一：用户两个日期都没输入。 这意味着用户想查询所有日期的数据。在SQL中，我们需要提供一个“无限大”的区间。在SAP中，通常用'00010101'代表最小日期，'99991231'代表最大日期。但更常见的做法是，如果字段是日期类型，可以直接用'00010101'和'99991231'。在ABAP SQL中，BETWEEN是包含端点的，所以这个区间覆盖了所有可能日期。

IF iv_date_from IS INITIAL AND iv_date_to IS INITIAL.
  lv_sql_date_from = '00010101'.
  lv_sql_date_to   = '99991231'.
ENDIF.

场景二：用户只输入了开始日期（或只输入了结束日期）。 比如用户只填了20240930，通常他的意思是“查询2024年9月30日之后的数据”或“查询2024年9月30日当天的数据”。为了简化逻辑，一种常见的、不会引起歧义的处理方式是：将单值查询视为查询某一特定时间点。即，将开始和结束都设为同一个值。

IF iv_date_from IS NOT INITIAL AND iv_date_to IS INITIAL.
  lv_sql_date_from = iv_date_from.
  lv_sql_date_to   = iv_date_from. " 结束日期等于开始日期
ENDIF.

IF iv_date_from IS INITIAL AND iv_date_to IS NOT INITIAL.
  lv_sql_date_from = iv_date_to. " 开始日期等于结束日期
  lv_sql_date_to   = iv_date_to.
ENDIF.

这样，BETWEEN '20240930' AND '20240930' 就会精确匹配日期为20240930的记录。如果用户本意是“大于等于20240930”，那么前端应该在传参时就把IV_DATE_TO设为一个很大的值（如99991231），或者后端采用不同的逻辑（如将单值作为开始，结束设为最大值）。这需要前后端约定一致。

场景三：用户输入了完整的开始和结束日期。 这是最理想的情况，直接使用即可。

IF iv_date_from IS NOT INITIAL AND iv_date_to IS NOT INITIAL.
  lv_sql_date_from = iv_date_from.
  lv_sql_date_to   = iv_date_to.
ENDIF.

将以上逻辑整合，就是原始文章中展示的代码块。这种IF-ELSEIF的瀑布流判断，覆盖了所有输入组合，确保了lv_sql_date_from和lv_sql_date_to最终都有合理的值，可以直接用于BETWEEN子句。

3.2 数字区间处理：原理相同，注意初始值

数字区间（比如金额、数量）的处理逻辑与日期区间完全一致。同样是处理空值、单值、双值三种情况。唯一需要特别注意的，就是数字类型的“空值”或“无效值”用什么来表示。

在ABAP中，数字类型字段（如INT4, DEC, J_1BEXBASE）的初始值是0。所以，我们通常用0来判断用户是否输入了值。

* 假设 ZMONEY_FROM, ZMONEY_TO 是类型为 J_1BEXBASE（金额）的输入参数
DATA: lv_money_from TYPE j_1bbase,
      lv_money_to   TYPE j_1bbase.

IF zmoney_from = 0 AND zmoney_to = 0.
  " 都没输入，给一个极大的范围
  lv_money_from = '-99999999'.
  lv_money_to   = '999999999'.
ELSEIF zmoney_from <> 0 AND zmoney_to = 0.
  " 只输入了开始金额，视为精确查询该金额点
  lv_money_from = zmoney_from.
  lv_money_to   = zmoney_from.
ELSEIF zmoney_from = 0 AND zmoney_to <> 0.
  " 只输入了结束金额，视为精确查询该金额点
  lv_money_from = zmoney_to.
  lv_money_to   = zmoney_to.
ELSE.
  " 两个金额都输入了
  lv_money_from = zmoney_from.
  lv_money_to   = zmoney_to.
ENDIF.

这里我用了-99999999到999999999作为默认范围，你需要根据实际业务中金额的可能取值范围来定义这个“极大”和“极小”值，确保能覆盖所有有效业务数据。

3.3 边界情况与陷阱提醒

在实际开发中，还有一些细节需要注意：

参数校验：对于日期，虽然我们用了CHAR8，但在拼接SQL前，最好能校验一下格式是否合法（比如月份是否在01-12，日期是否有效）。原始文章中的C#代码就做了这个工作。在ABAP中，你可以用函数DATE_CHECK_PLAUSIBILITY或者尝试用CONVERT DATE来转换，如果转换失败则视为非法输入。
顺序问题：务必保证lv_sql_date_from <= lv_sql_date_to。虽然我们的逻辑（单值时设为相等）已经保证了这一点，但如果前端传递了20240930到20240101这样的反向区间，你的程序应该如何处理？是自动交换两者，还是报错？这需要和业务方明确规则。一个健壮的程序可以增加一个判断：
```
IF lv_sql_date_from > lv_sql_date_to.
  DATA(lv_temp) = lv_sql_date_from.
  lv_sql_date_from = lv_sql_date_to.
  lv_sql_date_to = lv_temp.
ENDIF.
```
性能考量：BETWEEN是包含边界的。如果你的日期字段上建有索引，BETWEEN通常能很好地利用索引。但如果你用了LIKE '%'这种匹配所有的条件，可能会使索引失效，全表扫描。因此，在动态构建WHERE条件时，对于明确不需要过滤的字段，最好的做法是不要将其放入WHERE子句中，而不是使用LIKE '%'或BETWEEN 极小值 AND 极大值。

4. 完整RFC函数示例与逐行解析

下面，我们结合模糊查询和动态区间，来看一个增强版的完整RFC函数示例。这个函数ZSAP_LIGHT_ADS_GET用于查询一个名为ZTLIGHT_ADS的自定义表，它几乎囊括了前面讲到的所有技术点。

FUNCTION zsap_light_ads_get.
*"----------------------------------------------------------------------
*"*"本地接口：
*"  IMPORTING
*"     VALUE(ZTYPE)        TYPE CHAR10 OPTIONAL
*"     VALUE(ZSPNUMBER)    TYPE CHAR20 OPTIONAL
*"     VALUE(ZFPNUMBER)    TYPE CHAR50 OPTIONAL
*"     VALUE(VIN)          TYPE CHAR20 OPTIONAL
*"     VALUE(ZFPTYPE)      TYPE CHAR50 OPTIONAL
*"     VALUE(TTNAME)       TYPE CHAR50 OPTIONAL
*"     VALUE(SHNUMBER)     TYPE CHAR30 OPTIONAL
*"     VALUE(ZEMAIL)       TYPE CHAR50 OPTIONAL
*"     VALUE(ZBZ)          TYPE CHAR50 OPTIONAL
*"     VALUE(ZDATE_FROM)   TYPE CHAR8 OPTIONAL
*"     VALUE(ZDATE_TO)     TYPE CHAR8 OPTIONAL
*"     VALUE(ZMONEY_FROM)  TYPE J_1BEXBASE OPTIONAL
*"     VALUE(ZMONEY_TO)    TYPE J_1BEXBASE OPTIONAL
*"  TABLES
*"      OT_LIST            STRUCTURE  ZTLIGHT_ADS
*"----------------------------------------------------------------------

  DATA: lv_ztype      TYPE string,
        lv_zspnumber  TYPE string,
        lv_zfpnumber  TYPE string,
        lv_vin        TYPE string,
        lv_zfptype    TYPE string,
        lv_ttname     TYPE string,
        lv_shnumber   TYPE string,
        lv_zemail     TYPE string,
        lv_zbz        TYPE string.

  DATA: lv_date_from  TYPE char8,
        lv_date_to    TYPE char8,
        lv_money_from TYPE j_1bbase,
        lv_money_to   TYPE j_1bbase.

* ------------------------------------------------------------
* 第一部分：处理所有字符串字段的模糊查询模式
* ------------------------------------------------------------
* 为每个可能为空的字符串输入参数构造LIKE模式
* 如果输入为空，则模式为'%'，表示匹配所有
  lv_ztype     = COND #( WHEN ztype     IS NOT INITIAL THEN |%{ ztype }%| ELSE '%' ).
  lv_zspnumber = COND #( WHEN zspnumber IS NOT INITIAL THEN |%{ zspnumber }%| ELSE '%' ).
  lv_zfpnumber = COND #( WHEN zfpnumber IS NOT INITIAL THEN |%{ zfpnumber }%| ELSE '%' ).
  lv_vin       = COND #( WHEN vin       IS NOT INITIAL THEN |%{ vin }%| ELSE '%' ).
  lv_zfptype   = COND #( WHEN zfptype   IS NOT INITIAL THEN |%{ zfptype }%| ELSE '%' ).
  lv_ttname    = COND #( WHEN ttname    IS NOT INITIAL THEN |%{ ttname }%| ELSE '%' ).
  lv_shnumber  = COND #( WHEN shnumber  IS NOT INITIAL THEN |%{ shnumber }%| ELSE '%' ).
  lv_zemail    = COND #( WHEN zemail    IS NOT INITIAL THEN |%{ zemail }%| ELSE '%' ).
  lv_zbz       = COND #( WHEN zbz       IS NOT INITIAL THEN |%{ zbz }%| ELSE '%' ).

* ------------------------------------------------------------
* 第二部分：处理日期区间 (CHAR8格式，如20240901)
* ------------------------------------------------------------
  IF zdate_from IS INITIAL AND zdate_to IS INITIAL.
    " 场景1：都没填，查询全部日期
    lv_date_from = '00010101'.
    lv_date_to   = '99991231'.
  ELSEIF zdate_from IS NOT INITIAL AND zdate_to IS INITIAL.
    " 场景2：只填了开始日期，视为精确查询该日
    lv_date_from = zdate_from.
    lv_date_to   = zdate_from.
  ELSEIF zdate_from IS INITIAL AND zdate_to IS NOT INITIAL.
    " 场景3：只填了结束日期，视为精确查询该日
    lv_date_from = zdate_to.
    lv_date_to   = zdate_to.
  ELSE.
    " 场景4：开始和结束日期都填了
    lv_date_from = zdate_from.
    lv_date_to   = zdate_to.
    " 可选：增加一个逻辑，确保 from <= to
    IF lv_date_from > lv_date_to.
      DATA(lv_temp_date) = lv_date_from.
      lv_date_from = lv_date_to.
      lv_date_to   = lv_temp_date.
    ENDIF.
  ENDIF.

* ------------------------------------------------------------
* 第三部分：处理金额区间 (数字类型)
* ------------------------------------------------------------
  IF zmoney_from = 0 AND zmoney_to = 0.
    " 场景1：都没填，给一个极大的范围
    lv_money_from = '-99999999'.
    lv_money_to   = '999999999'.
  ELSEIF zmoney_from <> 0 AND zmoney_to = 0.
    " 场景2：只填了开始金额
    lv_money_from = zmoney_from.
    lv_money_to   = zmoney_from.
  ELSEIF zmoney_from = 0 AND zmoney_to <> 0.
    " 场景3：只填了结束金额
    lv_money_from = zmoney_to.
    lv_money_to   = zmoney_to.
  ELSE.
    " 场景4：开始和结束金额都填了
    lv_money_from = zmoney_from.
    lv_money_to   = zmoney_to.
    " 可选：确保 from <= to
    IF lv_money_from > lv_money_to.
      DATA(lv_temp_money) = lv_money_from.
      lv_money_from = lv_money_to.
      lv_money_to   = lv_temp_money.
    ENDIF.
  ENDIF.

* ------------------------------------------------------------
* 第四部分：执行最终的SQL查询
* ------------------------------------------------------------
  SELECT *
    FROM ztlight_ads
    INTO TABLE @ot_list
    WHERE ztype     LIKE @lv_ztype
      AND zspnumber LIKE @lv_zspnumber
      AND zfpnumber LIKE @lv_zfpnumber
      AND vin       LIKE @lv_vin
      AND zfptype   LIKE @lv_zfptype
      AND ttname    LIKE @lv_ttname
      AND shnumber  LIKE @lv_shnumber
      AND zemail    LIKE @lv_zemail
      AND zbz       LIKE @lv_zbz
      AND zdate    BETWEEN @lv_date_from AND @lv_date_to
      AND zmoney   BETWEEN @lv_money_from AND @lv_money_to.

ENDFUNCTION.

代码解析与亮点：

使用COND函数简化模糊查询拼接：我用了ABAP 7.4以后支持的COND函数，它比CONCATENATE语句更简洁。|%{ ztype }%|是字符串模板，效果和CONCATENATE一样。
清晰的逻辑分区：代码分为四个部分，分别处理字符串模糊、日期区间、数字区间和最终查询，结构非常清晰。
增加了边界检查：在日期和金额区间处理中，我增加了lv_date_from > lv_date_to的判断，并自动交换值。这使接口更加鲁棒，能容忍前端传递的非常规参数。
参数使用OPTIONAL：在接口定义中，所有IMPORTING参数都加了OPTIONAL关键字。这是一个好习惯，明确告诉调用者这些参数是可选的，并且在ABAP内部，未传递的OPTIONAL参数会保持其类型初始值（字符型为空，数字型为0），这正好与我们后续的IS INITIAL或= 0判断逻辑完美契合。

5. 前端校验：与非SAP系统（如C#）的协同

RFC接口是前后端分离的典范。后端（ABAP）逻辑写得再健壮，如果前端传递的数据本身就是“垃圾”，那也白搭。因此，在前端进行输入校验是至关重要的一环。原始文章中用C# WinForm程序作为例子，展示了前端应该如何准备数据。

5.1 前端校验的核心逻辑

前端校验的目标是：在调用RFC之前，确保传递给后端的数据是合法、合规、有意义的。对于我们的场景，主要校验两点：

日期格式合法性：用户可能在文本框里输入2024-13-01或abcd这样的非法日期。前端必须拦截这种输入，并给出友好提示，或者按照预定规则（如返回一个默认日期）处理后传给后端。
数字范围合理性：对于金额区间，要确保输入的是有效数字，并且开始值不大于结束值（如果业务要求的话）。

原始文章中的C#工具类MT提供了很好的示范：

DATE_CHECK方法：检查字符串是否为合法的yyyyMMdd格式。如果不是，弹出提示框，并返回一个默认值（如"20240930"）。这里的关键是，即使校验失败，也应该返回一个合法的、可预测的值给后端，而不是让程序崩溃或传递空字符串。这个默认值需要前后端共同约定。
num_from和num_to方法：将字符串转换为double类型。如果转换失败（输入非数字），则返回0。这正好对应了后端zmoney_from = 0表示“未输入”的逻辑。

5.2 前后端校验的职责划分

这里就引出了一个重要的设计原则：前后端校验的侧重点不同。

前端校验：侧重于用户体验和即时反馈。检查格式、必填项、简单的业务规则（如结束日期不小于开始日期）。发现错误时，立即通过对话框、标签变色等方式提示用户，阻止其进行下一步操作。
后端校验：侧重于数据完整性与业务安全性。进行更彻底的检查，包括数据是否存在、用户是否有权限、是否符合复杂的业务规则等。后端校验是数据进入系统的最后一道防线，必须坚不可摧。

在我们的例子中，前端对日期格式的校验属于“用户体验”范畴。即使前端漏掉了这个校验，传了一个'20241301'给后端，后端的BETWEEN语句在SAP HANA数据库上执行时可能会因为日期转换失败而抛出异常。所以，后端也应有相应的异常处理机制（TRY...CATCH），并将数据库错误转换为友好的业务错误信息返回给前端。

5.3 更佳实践：使用正则表达式进行严格校验

原始文章的C#代码用了IsValidDate函数，通过拆分字符串来校验日期。这是一种方法，但使用正则表达式可以更简洁、更强大。例如，校验yyyyMMdd格式：

public static bool IsValidDate(string dateString)
{
    if (string.IsNullOrEmpty(dateString) || dateString.Length != 8)
        return false;
    // 正则表达式：年份0001-9999，月份01-12，日期01-31（粗略校验）
    Regex regex = new Regex(@"^(?!0000)[0-9]{4}(0[1-9]|1[0-2])(0[1-9]|[12][0-9]|3[01])$");
    return regex.IsMatch(dateString);
}

这个正则表达式能快速过滤掉明显不合法的日期（如月份13）。当然，对于像2月30日这样的非法日期，仍然需要结合DateTime.TryParseExact等方法进行最终校验。

6. 性能优化与高级技巧

当数据量变大，或者查询条件非常复杂时，基础的LIKE和BETWEEN可能会遇到性能瓶颈。这里分享几个我实践中用到的优化技巧。

6.1 慎用`LIKE '%value%'`，尤其是字段开头的`%`

LIKE '%ABC%'这种模式，由于通配符在开头，数据库通常无法利用该字段上的标准B树索引，会导致全表扫描（Full Table Scan）。如果ZTLIGHT_ADS表有上百万行数据，同时有多个这样的模糊查询，性能会急剧下降。

优化建议1：尽可能使用后模糊查询（LIKE 'ABC%'） 如果业务允许，鼓励用户使用“以...开头”的查询方式。这样LIKE 'ABC%'是可以利用索引的。你可以在前端界面做引导，或者在后端逻辑中，如果判断输入值没有前置%，则自动采用后模糊。

优化建议2：对于确切的模糊查询，考虑使用全文检索 如果业务必须支持中间模糊（%ABC%），且数据量巨大，性能要求高，那么就需要寻求其他技术方案。SAP HANA数据库提供了强大的全文检索（Full Text Search）功能。你可以将需要模糊查询的字段（如ZBZ备注字段）创建全文索引，然后使用CONTAINS函数进行查询，其性能远高于LIKE。

* 假设已在HANA中为ZTEXT字段创建了全文索引
SELECT * FROM zdoc_table
  INTO TABLE @DATA(lt_result)
  WHERE CONTAINS(ztext, @lv_search_term, FUZZY(0.8)) = 1.

FUZZY(0.8)表示模糊度0.8，还能实现纠错查询，这是LIKE做不到的。

6.2 使用动态WHERE条件替代固定条件

我们之前的示例在WHERE子句中写死了所有条件。即使某个字段的查询模式是%（匹配所有），条件依然存在。更好的做法是使用动态WHERE子句，只添加那些真正需要过滤的条件。

DATA: lv_where TYPE string.

lv_where = `1 = 1`. " 一个永真条件，作为起点

IF lv_ztype <> '%'. " 只有当模式不是'%'时才添加条件
  CONCATENATE lv_where `AND ZTYPE LIKE @LV_ZTYPE` INTO lv_where SEPARATED BY space.
ENDIF.

IF lv_date_from <> '00010101' OR lv_date_to <> '99991231'.
  CONCATENATE lv_where `AND ZDATE BETWEEN @LV_DATE_FROM AND @LV_DATE_TO` INTO lv_where SEPARATED BY space.
ENDIF.

" 同理处理其他条件...

DATA: lt_result TYPE TABLE OF ztlight_ads.
SELECT * FROM ztlight_ads
  INTO TABLE lt_result
  WHERE (lv_where).

注意，动态WHERE子句需要使用WHERE (lv_where)这样的语法，并且要小心SQL注入风险。确保拼接进lv_where字符串的所有变量都是经过严格校验或使用绑定变量（如示例中的@LV_ZTYPE）的。在ABAP 7.52之后，更推荐使用NEW cl_abap_dyn_sql_statement( )等类来安全地构建动态SQL。

6.3 区间查询的索引利用与分区策略

对于BETWEEN条件，如果ZDATE或ZMONEY字段上有索引，查询效率通常很高。但是，如果日期范围跨度非常大（例如从00010101到99991231），实际上也是全表扫描，索引可能不会带来太大收益。

对于按时间序列增长的表（如日志表、交易表），使用数据库分区（Partitioning）是终极优化方案。例如，将ZTLIGHT_ADS表按ZDATE字段进行范围分区（Range Partition），每个月或每个季度一个分区。当查询限定在某个日期范围内时，数据库可以只扫描相关的分区，从而极大提升性能。但这属于数据库物理设计范畴，需要DBA的参与。

7. 总结与个人经验分享

回顾一下，要让一个ABAP RFC接口的查询功能既灵活又健壮，关键在于处理好两点：模糊查询的通用性和区间条件的动态适配。核心逻辑并不复杂，就是一堆IF-ELSE判断，但细节决定成败。

我印象最深的一个坑是早期没有处理日期区间的反向输入（结束早于开始）。测试人员输入了一个反向区间，程序没做处理直接传给数据库，结果查不出数据。测试报了个Bug：“查询功能异常”。排查了半天才发现是这个问题。自那以后，我在所有区间查询的逻辑里都加上了自动交换的防护代码。

另一个经验是关于默认值的选择。对于数字区间，用0作为“未输入”的标志是没问题的。但对于日期，用'00010101'和'99991231'有时会带来意想不到的问题，比如某些数据库函数或ABAP日期计算遇到这些极值会出错。后来在一些项目中，我们改用系统当前日期的前后100年作为默认范围，或者用CL_ABAP_TSTMP=>MAXIMUM等系统常量，更加安全。

最后，再强调一下前后端配合。这份ABAP代码提供了一个非常宽容的后端接口。作为接口开发者，我们当然希望调用方（前端）能传递规范的数据。但现实是，你永远不知道对方会怎么调你。所以，把后端接口设计得足够“傻”和“健壮”，能够消化各种“垃圾输入”并返回合理结果，是减少联调痛苦和线上故障的最有效方法。把复杂的校验和转换逻辑放在后端，让前端的工作尽可能简单，这往往是团队协作中最优的选择。