CONCAT在不同数据库中NULL处理不一致：MySQL遇NULL返回NULL，PostgreSQL/SQL Server将NULL视为空字符串；SUBSTRING索引从1开始；引号转义应使用QUOTE()等内置函数；建议统一用CONCAT并显式处理NULL。
CONCAT 在不同数据库里行为不一致，先看 NULL 怎么处理
MySQL 的
遇到
就直接返回
，哪怕其他参数全是字符串；PostgreSQL 和 SQL Server 的
（或等效函数）会把
当空字符串处理。这在拼接用户字段（比如
+
）时特别容易翻车——某字段为空，整条结果就没了。
实操建议：
MySQL 下稳妥写法是用
PostgreSQL 可直接用
，但注意它不接受
作为第一个参数时的隐式转换（某些旧版本有差异）
如果用的是 SQLite，它没有原生
，得用
操作符，且
结果仍是
，同样要
防御
SUBSTRING 索引从 1 开始，不是 0
几乎所有主流 SQL 方言（MySQL、PostgreSQL、SQL Server、Oracle）中，
（或
）的第一个字符位置都是 1，不是程序员习惯的 0。写成
不报错，但可能截出空值或意外结果——MySQL 会当成从第 1 位开始，PostgreSQL 则直接报错
。
实操建议：
统一用
表示取前 5 个字符，别图省事写 0
想从倒数第 n 位截取？MySQL 支持负数长度（
），但 PostgreSQL 不支持，得用
或
如果字段是
类型且超长，
性能通常比正则快，但别在 WHERE 条件里对大字段反复调用——加索引没用，考虑提前计算并存入冗余列
用 CONCAT 拼接带单引号的字符串，引号怎么转义最稳
动态拼接 SQL（比如生成 INSERT 语句或日志内容）时，若原始数据含单引号（如
），直接
会导致语法错误或 SQL 注入风险。不同数据库转义方式还不一样：MySQL 用两个单引号
，PostgreSQL 支持
也支持反斜杠
（需开启
），SQL Server 默认用两个单引号。
实操建议：
永远优先用参数化查询，避免手拼 SQL；真要拼，用数据库内置函数转义：
用
，
用
比手动替换
→
更可靠
别信“只过滤掉单引号就行”，换行符、反斜杠、Unicode 控制字符都可能破坏字符串边界——
类函数才是设计来干这事的
CONCAT 和 + 运算符混用，类型隐式转换会悄悄吃掉数据
SQL Server 允许用
拼接字符串，但遇到数字或日期会强制转成字符串，而这个转换规则很坑：
得到
，但
直接是
；更糟的是
在某些兼容模式下会报错，因为
被当成数学加法而非字符串连接。
实操建议：
统一用
，它对所有类型自动转字符串，且把
当空串（SQL Server 2012+、MySQL 5.7+、PostgreSQL 9.1+ 都支持）
如果必须用
（比如老系统），确保两边都是显式字符串类型：
别依赖数据库默认的
或
设置——它们可能被会话级配置覆盖，行为不可控
字符串截取和拼接看着简单，但跨数据库时连索引起点、NULL 处理、引号转义这些基础点都在打架。写一次就得查一遍文档，不是因为记不住，而是因为每个引擎真就各自为政。
CONCATNULLNULLCONCATNULLfirst_namelast_nameCONCAT(COALESCE(first_name, ''), ' ', COALESCE(last_name, ''))CONCAT(first_name, ' ', last_name)NULLCONCAT||NULL || 'abc'NULLCOALESCESUBSTRINGSUBSTRSUBSTRING(name, 0, 3)ERROR: substring index must be greater than zeroSUBSTRING(col, 1, 5)SUBSTRING(col, -3)RIGHT(col, 3)SUBSTRING(col, LENGTH(col) - 2)TEXTSUBSTRINGO'ReillyCONCAT('Name: ', name)''''\'standard_conforming_stringsMySQLQUOTE()PostgreSQLquote_literal()CONCAT(QUOTE(first_name), ' ', QUOTE(last_name))'''QUOTE+SELECT 'ID:' + 123ID:123SELECT 'ID:' + NULLNULLSELECT 'Price:' + 99.99+CONCATNULL+'ID:' + CAST(id AS VARCHAR(10))ANSI_NULLSCONCAT_NULL_YIELDS_NULL