substring_index是mysql原生轻量字符串分割函数，按固定分隔符截取前n段或后n段，不支持返回数组或遍历取值；需嵌套使用获取中间段，慎用于where条件以防索引失效。
MySQL 用 SUBSTRING_INDEX 按分隔符取前 N 段
直接说结论：SUBSTRING_INDEX 是 MySQL 原生、轻量、无需自定义函数的字符串分割方案，但只支持按固定分隔符从左或右截取“段数”，不能返回数组或逐个取值。
常见错误是把它当 Python 的 split() 用——比如想拆成多列再分别处理，结果发现只能取第 1 段、前 2 段、倒数第 1 段，没法遍历。
-
SUBSTRING_INDEX(str, delim, count)：第三个参数count是“切几刀后停”，正数从左往右切，负数从右往左切 - 例如
SUBSTRING_INDEX('a,b,c,d', ',', 2)→'a,b'；SUBSTRING_INDEX('a,b,c,d', ',', -2)→'c,d' - 想取中间某一段（比如第 3 个字段），得嵌套两次：先切前 3 段，再对结果切倒数 1 段，即
SUBSTRING_INDEX(SUBSTRING_INDEX(str, ',', 3), ',', -1) - 空分隔符或
count = 0会返回空字符串，不是 NULL，注意后续IS NULL判断会失效
PostgreSQL / SQL Server / Oracle 怎么办？没有 SUBSTRING_INDEX
这些数据库压根不认 SUBSTRING_INDEX，硬写会报错 function substring_index does not exist 或类似提示。
替代方案取决于你实际要做什么：
- 只要取第一个分隔符前/后的部分：用
STRPOS+LEFT/SUBSTR（PostgreSQL/SQL Server）或INSTR+SUBSTR（Oracle）手动定位 - 需要拆成行（比如把逗号列表转成多行记录）：PostgreSQL 用
STRING_TO_ARRAY+UNNEST；SQL Server 用STRING_SPLIT（2016+）；Oracle 12c+ 可用REGEXP_SUBSTR配合CONNECT BY - 只是临时解析一两个字段，别折腾函数，导出到脚本里用 Python/awk 处理更稳
SUBSTRING_INDEX 在 WHERE 条件里用的坑
看似方便，但容易触发全表扫描，尤其在大表上性能断崖式下跌。
典型错误写法：WHERE SUBSTRING_INDEX(email, '@', -1) = 'gmail.com' —— 这会让 MySQL 无法使用 email 字段上的索引。
- 原因：函数作用于字段，优化器无法下推索引查找
- 如果高频按域名查，建生成列 + 索引更靠谱：
ALTER TABLE users ADD COLUMN domain VARCHAR(64) STORED AS (SUBSTRING_INDEX(email, '@', -1))，再给domain加索引 - 临时应急可用
LIKE替代（如email LIKE '%@gmail.com'），但要注意它只能走后缀索引（需反转字段存储）或全文索引，不是万能解
分割后取值为空或乱码？检查这三处
不是函数有问题，大概率是数据本身或字符集埋了雷。
- 源字段含不可见字符（比如 Windows 换行
\r\n或零宽空格），导致分隔符实际没对齐；用HEX(col)查看真实字节 - 表/列字符集是
utf8（非utf8mb4），遇到 emoji 或某些生僻字会被截断，分割位置偏移；确认用的是utf8mb4_unicode_ci - 分隔符是全角逗号、中文顿号、空格等，而代码里写了半角符号；建议先
SELECT DISTINCT HEX(delim_col) FROM ...看实际存储的十六进制值
复杂点永远在数据里，不在函数文档里。
