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