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

【问题标题】：Is there performance difference between concat vs || in oracleconcat 与 || 之间是否存在性能差异？在甲骨文中
【发布时间】：2014-11-24 00:44:06
【问题描述】：

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

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

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

【问题讨论】：

标签： oracle 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），所以我正在切换到 ||。