触发器函数中字符串拼接：使用||操作符还是format()函数？

很多人觉得这两个的选择全看个人代码风格，其实完全不是。二者有明确的能力边界和适用场景差异，不存在谁可以完全替代谁的情况。 #

二者的核心特性与实际优势 #

|| 拼接操作符 #

作为SQL标准定义的原生字符串拼接语法，它的设计目标就是最直接的线性文本拼接：

• 语法逻辑零门槛：从左到右按操作数顺序拼接，完全符合人对“把几个字符串连起来”的直观认知，不存在额外的占位符解析逻辑
• 执行开销最低：在无额外处理的纯拼接场景下，解析和执行的链路比format()更短，性能差距虽然在触发器场景下可以忽略，但语法上没有冗余
• 类型兼容稳定：只要操作数可以隐式转换为文本类型，就可以直接参与拼接，不需要提前做显式类型转换

format() 格式化函数 #

这是内置的字符串处理函数，核心能力是带控制逻辑的格式化输出，而不是单纯的文本拼接：

• 自带安全转义能力：通过内置占位符自动处理特殊字符——%s负责普通文本转换、%I自动将输入转为合法SQL标识符（自动加双引号、转义特殊符号）、%L自动将输入转为合法SQL字面量（自动转义单引号、处理NULL值）。这是它最核心、||完全无法替代的能力，尤其在触发器动态SQL构建场景下能直接避免注入风险和语法错误
• 多参数场景下可读性更高：拼接超过3个动态参数的长文本时，format()通过占位符和实参分离的写法，能减少一长串||加单引号带来的视觉噪音，降低漏写引号、漏加拼接符的低级错误概率
• 内置格式控制能力：支持指定数字精度、日期输出格式、文本填充规则等，这些效果是纯拼接需要额外写转换函数才能实现的

通用选型判断逻辑 #

选型的核心判断依据是拼接需求的能力要求，而非单纯看拼接的文本长度：

• 优先选||操作符的场景：
  • 无转义需求、无格式控制要求的短距离线性拼接，比如给固定前缀的日志加个简单的文本后缀
  • 拼接片段少、逻辑完全线性，写出来的代码不存在语法符号冗余的场景
• 优先选format()函数的场景：
  • 拼接内容涉及动态SQL构建：尤其是需要动态指定表名、字段名的逻辑，必须依靠%I/%L做自动转义，手动用||拼接很容易因为漏转义特殊字符触发语法错误，甚至引入注入风险
  • 拼接的动态参数超过3个，或者动态值可能包含单引号、双引号、换行等特殊字符的场景
  • 需要对拼接的动态值做格式转换（比如保留数字精度、转成指定格式的时间字符串）的场景

注：内容的提问来源于stack exchange，提问作者HummingBird24