CONVERT_TZ函数支持下推到存储层吗？

OceanBase 技术问题
#1

@论坛小助手 执行计划看下推存储层失败

CONVERT_TZ函数下推存储层失败.pong
CONVERT_TZ函数下推存储层失败.pong1019×669 15 KB

_pushdown_storage_level参数值为4，存储层下推功能已开启到最高级别

_pushdown_storage_level参数值为4
_pushdown_storage_level参数值为41654×407 82.8 KB

1 个赞
#3

用户的问题是关于 CONVERT_TZ 函数在执行计划中未能下推到存储层，即使参数 _pushdown_storage_level 已设置为 4。这可能涉及到 SQL 执行计划的优化问题或函数下推的限制。

日志采集场景: SQL性能问题

日志采集命令:

obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='Yxx'}"

此命令用于收集与 SQL 性能相关的信息，包括执行计划、系统参数配置等，以便分析为何 CONVERT_TZ 函数未能下推到存储层。

为了更好地帮助您解决问题，请您提供以下信息：

  1. 您当前使用的 OceanBase 数据库版本是什么？不同版本可能存在不同的函数下推支持情况。
  2. 能否提供具体的 SQL 语句以及对应的执行计划（EXPLAIN 输出）？这有助于我们了解 CONVERT_TZ 的使用上下文。
  3. 参数 _pushdown_storage_level 是否全局生效？您可以通过查询 gv$parameter 系统视图确认该参数的实际值。
  4. 是否有其他类似的函数（如 STR_TO_DATE 或 DATE_FORMAT）能够成功下推到存储层？如果有，请提供对比案例。
  5. 您是否尝试过重启 OBServer 以确保参数变更生效？如果未尝试，请尝试后观察问题是否解决。

请根据上述命令采集日志，并将生成的日志压缩包提供给我们，以便进一步分析问题原因。

附上敏捷诊断工具 obdiag 使用帮助链接

1 个赞
#4

ob版本是多少

1 个赞
#5

4.3.5.1

#6

根据您提供的 OceanBase 数据库版本为 4.3.5.1，以及问题描述和相关文档信息，我将综合分析 CONVERT_TZ 函数未能下推到存储层的原因。

已知信息总结

  1. 参数配置：

    • 参数 _pushdown_storage_level 已设置为 4，表示存储层下推功能已开启到最高级别。
    • 根据执行计划，CONVERT_TZ 函数未能下推到存储层。

  2. 执行计划：

    • 执行计划显示 CONVERT_TZ 函数在计算层完成，未下推到存储层。
    • 查询语句为：
      SELECT * 
FROM oc_order o 
WHERE CONVERT_TZ(o.date_modified, 'America/Los_Angeles', 'Asia/Tokyo') = '2025-04-01';

  3. 数据库版本：

    • 当前使用的是 OceanBase 社区版 4.3.5.1。

分析与解答

1. 函数下推支持情况

根据 OceanBase 的设计，某些内置函数（如 CONVERT_TZ）可能不支持直接下推到存储层。这是由于以下原因：

  • 时间戳转换依赖时区信息：CONVERT_TZ 函数需要依赖系统时区配置（time_zone 参数），而时区信息通常由计算层维护，存储层并不具备完整的时区映射表。
  • 社区版限制：在 OceanBase 社区版中，部分复杂函数（如 CONVERT_TZ、STR_TO_DATE 等）可能未完全支持存储层下推。

2. 参数 _pushdown_storage_level 的作用

参数 _pushdown_storage_level 控制存储层下推的级别，具体含义如下：

  • 0：关闭存储层下推。
  • 1：仅支持块扫描（blockscan）。
  • 2：支持块扫描和过滤（filter）。
  • 3：支持块扫描、过滤和聚合（aggregate）。
  • 4：支持块扫描、过滤、聚合和分组（group by）。

虽然该参数已设置为 4，但其作用范围仅限于支持下推的函数和操作符。对于不支持下推的函数（如 CONVERT_TZ），即使参数值为 4，也无法实现存储层下推。

3. 优化建议

为了提高查询性能，您可以尝试以下方法：

  • 避免使用 CONVERT_TZ 函数：
    如果可能，将时区转换逻辑移至应用层完成，或者在数据插入时统一存储为 UTC 时间，查询时再进行时区转换。

  • 改写查询条件：
    将 CONVERT_TZ 函数从过滤条件中移除，改为直接比较时间戳。例如：

    SELECT * 
FROM oc_order o 
WHERE o.date_modified >= '2025-04-01T00:00:00' AND o.date_modified < '2025-04-02T00:00:00';

    这样可以充分利用索引加速查询。

  • 检查时区配置：
    确保系统时区配置正确，可以通过以下命令查看：

    SHOW VARIABLES LIKE '%time_zone%';

  • 升级到更高版本：
    如果业务场景对 CONVERT_TZ 函数的存储层下推有强需求，可以关注后续版本的更新说明，或考虑使用企业版以获得更全面的功能支持。

结论

根据文档库中的信息和您的问题描述，CONVERT_TZ 函数在 OceanBase 社区版 4.3.5.1 中暂不支持存储层下推。这是由于时区转换逻辑的复杂性以及社区版的功能限制所致。建议通过改写查询条件或调整业务逻辑来优化性能。

如果您仍有疑问，或需要进一步技术支持，请联系 OceanBase 官方团队获取帮助。

具体信息可参考以下文档:

  1. compatible
  2. optimizer_features_enable
  3. 升级 Agent
  4. 物理备份与恢复概述
  5. Agent 升级检查
  6. ob_compatibility_version
  7. min_observer_version
  8. OceanBase 数据库升级检查

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

1 个赞
#7

感觉问题我都没有看太懂啊 :joy:

1 个赞
#8

开启了函数下推到存储层计算功能，函数按理要下推到存储层进行计算；
但是看执行计划，没有下推到存储层，还是在计算层进行的过滤。

#9

table_scan算子上的filter默认都是下推到存储的 执行计划是看不到下推的

1 个赞
#10

那从什么地方可以判断，函数是否成功下推到存储层？

#11

默认table_scan都是下推的

1 个赞
#12

好的感谢