子查询不能替代SUBSTRING类函数，因其本质是返回结果集的SELECT语句，无法直接参与字符串计算；必须用嵌套函数（如INSTR+SUBSTRING或SUBSTRING_INDEX）在SELECT或WHERE中完成定位与切片。
不能靠子查询直接提取字符串特定部分——子查询返回结果集，而字符串截取需要标量函数。必须用嵌套函数（如 INSTR + SUBSTRING 或 SUBSTRING_INDEX）在 SELECT 或 WHERE 中完成定位与切片。
为什么子查询不能替代 SUBSTRING 类函数
子查询本质是返回一行或多行数据的 SELECT 语句，它无法直接参与字符串计算。比如你写 (SELECT email FROM users WHERE id = 1) 是合法子查询，但把它当参数塞进 SUBSTRING(...) 会报错，因为 SQL 不允许把子查询结果直接当字符串位置或长度用（除非显式转换且上下文支持）。
常见错误现象：
-
SUBSTRING((SELECT email FROM users LIMIT 1), INSTR(email, '@') + 1)—— 这里email在子查询外未定义，报Unknown column 'email' -
SUBSTRING((SELECT email FROM users LIMIT 1), 1, 5)—— 看似可行，但 MySQL 会报Subquery returns more than 1 row（若没加 LIMIT 或条件不唯一）
真正能用的，是把子查询结果作为字段名参与函数调用，例如：SUBSTRING(t.email, INSTR(t.email, '@') + 1)，其中 t 来自 FROM 子句的表别名。
SUBSTRING_INDEX 是最简方案，但只适用于分隔符场景
MySQL 特有函数 SUBSTRING_INDEX 能一步完成“按第 N 次出现的分隔符切分”，比嵌套 INSTR 更安全、更易读，且自动处理不存在分隔符的情况（返回原串）。
使用场景：邮箱用户名、域名、路径最后一级、URL 协议头等。
- 取
user@example.com中 @ 前的部分：SUBSTRING_INDEX('user@example.com', '@', 1) - 取
https://api.example.com/v2/users中协议名：SUBSTRING_INDEX('https://api.example.com/v2/users', '://', 1) - 取
a.b.c.d中第二个点之后的内容（即c.d）：SUBSTRING_INDEX(SUBSTRING_INDEX('a.b.c.d', '.', 3), '.', -1)—— 先取前3段，再从右截1段
注意：SUBSTRING_INDEX 的第三个参数为负数时，是从右往左数。它不依赖字符位置计算，天然规避 INSTR 返回 0 导致 SUBSTRING 出错的问题。
嵌套 INSTR + SUBSTRING 用于复杂定位逻辑
当需要“第 N 次出现的位置”“跳过前 M 次匹配”或“结合其他条件动态算起始点”时，INSTR 嵌套是绕不开的。但必须手动处理边界情况。
关键风险点：
-
INSTR找不到目标时返回 0，直接传给SUBSTRING(str, 0, len)会截出空字符串（MySQL 中位置从 1 开始，0 无效） - 嵌套层级一多，可读性断崖下降，例如第二次
INSTR要从第一次位置 + 1 开始搜：INSTR(str, '.', INSTR(str, '.') + 1) - 如果字段含 NULL，整个表达式结果为 NULL，不会报错但可能漏数据
安全写法示例（取 a.b.c.d 中第二个点后的全部内容）：
SUBSTRING(
'a.b.c.d',
INSTR('a.b.c.d', '.', INSTR('a.b.c.d', '.') + 1) + 1
)
等价于：'c.d'。但注意：这个表达式无法处理只有 1 个点或 0 个点的情况，生产环境建议包裹 CASE WHEN INSTR(...) > 0 THEN ... ELSE ... END。
兼容性与版本陷阱
不同数据库对字符串函数的支持差异很大，别想一套 SQL 走天下：
- MySQL 5.7 及以下：没有
REGEXP_SUBSTR，只能靠SUBSTRING_INDEX或嵌套INSTR - MySQL 8.0+：支持
REGEXP_SUBSTR(str, pattern, pos, occurrence)，可精准匹配第 N 次正则结果，但性能比SUBSTRING_INDEX差不少 - PostgreSQL：用
SUBSTR(str, start, len)+POSITION(substr IN str)，且POSITION找不到返回 0，同样要判空 - SQL Server：用
SUBSTRING(str, start, len)+CHARINDEX(substr, str)，CHARINDEX找不到返回 0，行为一致
最容易被忽略的是：所有这些函数对 NULL 输入都静默返回 NULL，而不是报错。查不出结果时，先 WHERE col IS NOT NULL 排查，比调函数逻辑更快。
