substring函数在主流数据库中均支持但存在关键差异：mysql和postgresql用1-based索引、语法为substring(str,pos,len)或substring(str from pos for len)，sql server同为1-based且语法一致，oracle则使用substr(str,pos,len)函数名；起始位置为0时，mysql返回空、sql server自动修正为1、postgresql报错。

SUBSTRING 函数在不同数据库中的写法差异

MySQL、PostgreSQL、SQL Server 和 Oracle 都支持 SUBSTRING，但参数顺序和起始位置规则不一致，直接照搬容易报错。MySQL 和 PostgreSQL 用 1-based 索引（第一个字符位置是 1），SQL Server 也是；Oracle 的 SUBSTR 同样是 1-based，但函数名不同。

常见错误现象：SUBSTRING(text, 0, 5) 在 MySQL 中会返回空，在 SQL Server 中则被当作从第 1 位开始（自动修正），而在 PostgreSQL 中会报错“zero not allowed as offset”。

• MySQL / PostgreSQL：SUBSTRING(column_name, start_pos, length)
• SQL Server：SUBSTRING(column_name, start_pos, length)（start_pos 不能为 0）
• Oracle：SUBSTR(column_name, start_pos, length)（函数名是 SUBSTR，不是 SUBSTRING）

提取固定位置的子串：比如取邮箱用户名部分

假设字段 email 值为 alice@example.com，想提取 @ 之前的内容。不能硬写 SUBSTRING(email, 1, 5)，因为长度不固定，得结合 LOCATE 或 CHARINDEX 动态算位置。

• MySQL：SUBSTRING(email, 1, LOCATE('@', email) - 1)
• SQL Server：SUBSTRING(email, 1, CHARINDEX('@', email) - 1)
• PostgreSQL：SUBSTRING(email FROM 1 FOR POSITION('@' IN email) - 1)

注意：如果字段可能不含 @，上述表达式会返回 NULL 或报错（如 PostgreSQL 中 POSITION 找不到时返回 0，导致 FOR -1 报错）。生产环境务必加 CASE WHEN 判断。

处理截断越界：length 参数超出剩余字符数怎么办

SUBSTRING 对超长 length 是安全的——它不会报错，而是自动截取到字符串末尾。例如 SUBSTRING('abc', 2, 10) 返回 'bc'，不是报错或补空格。

但这个“宽容”容易掩盖逻辑错误。比如你想取后 3 位，写成 SUBSTRING(col, LENGTH(col) - 2, 3)，当 col 长度小于 3 时，LENGTH(col) - 2 可能 ≤ 0，触发前述的索引异常（尤其在 PostgreSQL 中）。

• 更稳妥的写法（MySQL）：SUBSTRING(col, GREATEST(1, LENGTH(col) - 2), 3)
• SQL Server 可用 IIF(LEN(col) >= 3, SUBSTRING(col, LEN(col)-2, 3), col)
• 别依赖“自动截断”来省略边界检查，尤其当字段来自用户输入或外部系统时

性能与可读性权衡：正则 vs SUBSTRING

遇到复杂模式（如“提取括号内内容”或“跳过前两个单词取第三个”），硬套 SUBSTRING + 多层 LOCATE 会让 SQL 变得难读且难维护。这时该考虑数据库是否支持正则：

• MySQL 8.0+ 支持 REGEXP_SUBSTR()，比嵌套 SUBSTRING 清晰得多
• PostgreSQL 有 substring() 的正则重载：substring(col FROM '\(([^)]+)\)')
• SQL Server 2017+ 不原生支持正则，需用 CLR 或字符串拆分函数模拟

单纯提取定长前缀/后缀或单一分隔符内容，SUBSTRING 更轻量、兼容性更好；一旦出现嵌套分隔、可选段落或模糊匹配，就该换思路——否则调试时连自己都看不懂那串 SUBSTRING(SUBSTRING(...)) 是在干啥。