concat 与 || 之间是不是存在性能差异？在甲骨文中

Posted 2023-02-24

【中文标题】concat 与 || 之间是不是存在性能差异？在甲骨文中

【英文标题】：Is there performance difference between concat vs || in oracleconcat 与 || 之间是否存在性能差异？在甲骨文中

【发布时间】：2014-11-24 00:44:06

【问题描述】：

我想在 oracle sql 查询中连接多个 (3) 列。目前我正在使用函数concat。 有人建议使用|| 代替concat，因为它可以提高性能。

这是真的吗？如果是，为什么？

我只看到 || 的好处那个书面查询是否更具可读性。

【参考方案1】：

两者完全相同，CONCAT() 用于支持不同的字符集进行 SQL 脚本处理，其中'||' 可能会被错误解释。

来自Documentation

在大多数平台上，连接运算符是两个实心垂直 条，如表 4-3 所示。但是，一些 IBM 平台使用损坏的 此运算符的竖线。在之间移动 SQL 脚本文件时 具有不同字符集的系统，例如在 ASCII 和 EBCDIC，竖线可能不会翻译成竖线 目标 Oracle 数据库环境所需。甲骨文提供 CONCAT 字符功能可替代竖线 难以或无法控制的情况下的操作员 由操作系统或网络实用程序执行的翻译。采用 将在环境之间移动的应用程序中的此功能 具有不同的字符集。

【参考方案2】：

我设置了一个简单的 PL/SQL 脚本（如下），在一个循环中尝试两个连接选项，每个选项 1 亿次。 || 的结果是 142.93 秒，CONCAT 是 144.11 秒。无论哪种方式，您所说的每次操作大约需要 1.4 微秒。我的结论是，似乎没有任何明显的性能差异。

除了更具可读性之外，|| 还是串联运算符的 ANSI 标准。

---

DECLARE
   i NUMBER;
   j NUMBER := 100000000;
   v VARCHAR2 (1000);
   v_start TIMESTAMP := SYSTIMESTAMP;
BEGIN
   FOR i IN 1 .. j LOOP
      v := DBMS_RANDOM.VALUE () || DBMS_RANDOM.VALUE ();
   END LOOP;    
   DBMS_OUTPUT.put_line ('1: ' || (SYSTIMESTAMP - v_start));
END;

DECLARE
   i NUMBER;
   j NUMBER := 100000000;
   v VARCHAR2 (1000);
   v_start TIMESTAMP := SYSTIMESTAMP;
BEGIN
   FOR i IN 1 .. j LOOP
      v := CONCAT (DBMS_RANDOM.VALUE (), DBMS_RANDOM.VALUE ());
   END LOOP;    
   DBMS_OUTPUT.put_line ('2: ' || (SYSTIMESTAMP - v_start));
END;

---

作为脚注，Oracle 说明了CONCAT 函数的用途：

在不同系统之间移动 SQL 脚本文件时 字符集，例如在 ASCII 和 EBCDIC 之间，竖线可能 不能翻译成目标Oracle要求的竖线 数据库环境。 Oracle 提供的 CONCAT 字符函数为 竖线运算符的替代方案，适用于以下情况 难以或不可能控制通过操作执行的翻译 系统或网络实用程序。在应用程序中使用此功能 将在具有不同字符集的环境之间移动。

【讨论】：

我的一些同事表示他们使用管道的查询有时会失败，而 CONCAT 函数则不会。我不认为在我们的情况下这是不同字符集的问题，但网络/操作系统问题很有趣。我正在将 C7 .imr 文件转换为 C10（基于 Web），所以我正在切换到 ||。