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