SUBSTRING函数不报错的关键是适配数据库的起始位置（MySQL/PG/SQL Server从1开始）并避免越界；测试用SELECT SUBSTRING('hello',1,2)验证，结合POSITION/CHARINDEX动态计算位置，NULL值需COALESCE处理。
SQL里SUBSTRING函数怎么写才不报错？
不同数据库对
的参数顺序和起始位置约定不一致，直接照搬语法大概率出错。MySQL 和 PostgreSQL 从 1 开始计数，SQL Server 也是；但 SQLite 默认从 1 开始，而某些旧版本或兼容模式下可能表现异常。
实操建议：
永远显式写出参数名（如果数据库支持），比如 PostgreSQL 可用
提高可读性
在不确定环境时，先用
测试——结果是
才说明从 1 开始；如果是空或报错，可能需要改成
避免硬写负数起始位，除非明确知道当前数据库是否支持（PostgreSQL 支持，MySQL 不支持）
截取文件扩展名、域名、手机号中间四位的典型场景
真实业务中不是单纯“取第3到第5个字符”，而是有语义的切分，得结合
、
或
动态算位置。
例如提取邮箱域名部分（
→
）：
再比如取文件扩展名（假设路径为
）：
注意点：
MySQL 没有
配合
的简洁写法，得用
替代
SQL Server 要用
而非
，且索引从 1 开始，逻辑一致但函数名不同
如果字段可能为
或不含分隔符，
会返回
或空字符串，别漏掉
或
处理
SUBSTRING配合WHERE做模糊前缀匹配比LIKE更高效？
不是更高效，反而通常更慢——因为
无法走索引，而
在有索引时可以范围扫描。
只有当必须匹配非前缀位置时（比如“第4~6位是xyz”），才被迫用
，此时性能天然受限。
能用
就别绕路，尤其注意：
等价于
（多数数据库支持），但
更直观，且部分引擎对它有额外优化
想查“以某串结尾”，用
或
，别用
，易错且难维护
正则虽灵活（如 PostgreSQL 的
），但跨库兼容性差，简单截取别过早引入
为什么SUBSTRING('abc', 5, 1)不报错却返回空？
这是设计行为，不是 bug。所有主流 SQL 引擎都定义：当起始位置超出字符串长度，或截取长度为负/零，
安静返回空字符串（
），而不是抛异常。
这意味着你不能靠报错来发现逻辑错误，得主动校验：
用
在 ETL 或应用层做数据探查时，记得检查目标字段的长度分布，避免大量
返回空却误以为成功
PostgreSQL 还提供
的正则变体，但它在 pattern 不匹配时也返回
，行为不统一，混用时格外小心
最麻烦的从来不是函数怎么写，而是不同数据库对“位置从几开始”“越界怎么处理”“空输入怎么响应”的隐式约定——写之前，先
三连查，比看文档快。
SUBSTRINGSUBSTRING(str FROM start FOR length)SELECT SUBSTRING('hello', 1, 2)he0POSITIONCHARINDEXLENGTHuser@domain.comdomain.comSELECT SUBSTRING(email FROM POSITION('@' IN email) + 1)/path/to/file.txtSELECT SUBSTRING(filename FROM LENGTH(filename) - POSITION('.' IN REVERSE(filename)) + 2)REVERSEPOSITIONLOCATE('.', REVERSE(filename))CHARINDEXPOSITIONNULLSUBSTRINGNULLCOALESCECASESUBSTRING(col, 1, 3) = 'abc'col LIKE 'abc%'SUBSTRINGLIKESUBSTRING(col, 1, n)LEFT(col, n)LEFTRIGHT(col, n)col LIKE '%abc'SUBSTRING(col, LENGTH(col)-n+1)REGEXP_REPLACESUBSTRING''CASE WHEN LENGTH(str) 显式兜底SUBSTRINGSUBSTRING(str FROM pattern)NULLSELECT SUBSTRING('test', 0, 1), SUBSTRING('test', 1, 1), SUBSTRING('test', 5, 1)