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(...)) 是在干啥。
