外表查询慢的已知问题和排查思路

总结说明

在 OceanBase 数据库中，外表（External Table）功能允许用户直接查询存储在外部系统（如 HDFS、S3、本地文件系统等）中的数据，而无需将数据导入 OceanBase 内部表。外表查询执行慢或超时问题的诊断有其特殊性。本文档介绍外表查询的已知问题和排查思路。

详细说明

问题一：简单外表查询挂起（Hang）直至超时

问题现象

执行简单的外表查询时，SQL 语句挂起（Hang）直至超时。使用相同的 DDL 创建新外表后，新表查询正常。

问题分析

根据原始查询的 trace_id 查看执行日志，发现内部 SQL（Inner SQL）数量异常增多，导致查询在重复刷新（Refresh）过程中超时。

内部 SQL 示例如下：

UPDATE __all_external_table_file
SET CREATE_VERSION = CASE WHEN DELETE_VERSION != 9223372036854775807 THEN 1745548742797645 ELSE CREATE_VERSION END,
    DELETE_VERSION = 9223372036854775807,
    FILE_SIZE = 1444817
WHERE TABLE_ID = 523280
  AND PART_ID = 523315
  AND FILE_ID = 1;

SELECT file_url, file_id, file_size
FROM __all_external_table_file
WHERE table_id = 523280
  AND part_id = 523316;

已知问题

创建外表后，首次访问外表时会触发自动刷新（Auto Refresh）以获取最新的数据文件信息。如果外表创建后，其底层数据文件发生过删除操作，则可能触发此问题。

修复版本

• V4.3.5 BP1(oceanbase-4.3.5.1-101010012025031723)
• V4.3.5 BP0 Hotfix6(oceanbase-4.3.5.0-100060022025031922)

规避方式

避免使用 IMMEDIATE 方式自动刷新。建议在执行查询 SQL 前，显式执行 ALTER EXTERNAL TABLE 命令手动刷新外表。

ALTER EXTERNAL TABLE table_name REFRESH;

问题二：非分区外表数据量大导致查询耗时高

问题现象

查询非分区外表时，如果表中数据量较大，查询耗时显著增加。

问题分析

从日志中观察发现，对于非分区外表，查询会从第一条记录开始顺序读取所有数据文件。当外表对应的底层文件数量多、体积大时，这种顺序读取方式会导致查询性能低下。

日志片段显示大量对 S3 存储的慢速读取操作，最终查询超时。

解决办法

对于数据量较大的外表，建议将其创建为分区表，以利用分区剪裁（Partition Pruning）特性提升查询性能。

常用外表诊断语句

以下 SQL 语句可用于辅助诊断外表相关问题：

1. 查询外表的数据文件数量

   SELECT COUNT(*)
   FROM oceanbase.dba_ob_external_table_files
   WHERE table_name = 'your_external_table_name';
   

2. 关闭外表的自动刷新

   关闭自动刷新可以提升访问速度，但需要注意，此后外表元数据可能无法反映外部数据的最新变化。

   ALTER EXTERNAL TABLE your_external_table_name AUTO_REFRESH = OFF;
   

3. 根据日志中的文件路径查找文件归属信息

   当日志中出现特定文件路径的慢查询记录时，可以使用此语句查看该文件所属的表、分区及大小等信息。

   SELECT *
   FROM oceanbase.dba_ob_external_table_files
   WHERE FILE_URL LIKE '%your_file_pattern%';
   

适用版本

OceanBase 数据库 V4.x 版本。