substring_index不是split，只切一刀：正数count从左取到第count个分隔符前（含前面所有字段和分隔符），负数count从右取到倒数第abs(count)个分隔符后，count=0返回空字符串。
SUBSTRING_INDEX不是split，它只切一刀
很多人写 SUBSTRING_INDEX('a,b,c', ',', 2) 期望得到 'b'，结果拿到 'a,b'——这说明没理解函数本质：SUBSTRING_INDEX 不是“取第 N 段”，而是“切到第 N 次分隔符位置为止”。它返回的是一个子字符串，不是数组，也不自动遍历。
- 正数
count：从左往右找第count个分隔符，返回它左边全部（含前面所有字段和中间分隔符） - 负数
count：从右往左找倒数第abs(count)个分隔符，返回它右边全部 -
count = 1→ 第一个分隔符前；count = -1→ 最后一个分隔符后；count = 0返回空字符串，别用 - 如果分隔符实际出现次数 abs(count)，函数直接返回原字符串，不报错也不截断
想取第 N 个字段？必须嵌套两次调用
要从 'apple,banana,orange,grape' 中准确拿到第 3 个值 'orange'，单靠一次 SUBSTRING_INDEX 不行。得先“切到第 3 段为止”，再“从结果里取最后一段”：
SUBSTRING_INDEX(SUBSTRING_INDEX('apple,banana,orange,grape', ',', 3), ',', -1)
- 内层
SUBSTRING_INDEX(..., ',', 3)→'apple,banana,orange' - 外层
SUBSTRING_INDEX(..., ',', -1)→'orange' - 顺序不能反：如果先
-1再3，会越切越短甚至为空 - 字段数不固定时（如有的记录只有 1 个逗号），需先算总段数防越界：
LENGTH(str) - LENGTH(REPLACE(str, ',', '')) + 1
拆成多行（行转列）必须借力系统表
MySQL 没有 GENERATE_SERIES 或内置序号生成器，SUBSTRING_INDEX 自身无法循环。常见且稳定的做法是关联 mysql.help_topic 表，利用其连续的 help_topic_id（从 1 开始）模拟下标：
SELECT
SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c,d', ',', b.help_topic_id), ',', -1) AS item
FROM mysql.help_topic b
WHERE b.help_topic_id
-
help_topic_id必须 ≥ 1，否则第一项漏掉 - WHERE 条件里的计算式才是真实段数，不是硬写
- 注意：该表在某些精简版 MySQL 或云数据库（如阿里云 RDS 默认禁用）中可能不可用，需确认权限与存在性
- 若不可用，可建临时数字表，或改用应用层处理——强行造序列反而更重
跨数据库别硬搬，SUBSTRING_INDEX 是 MySQL 独占语法
在 PostgreSQL、SQL Server 或 Oracle 里直接写 SUBSTRING_INDEX，必然报错：function substring_index does not exist。不同库拆分逻辑差异大，别幻想一套 SQL 走天下：
- PostgreSQL：用
STRING_TO_ARRAY(str, ',')+UNNEST()拆成行；取第 N 项用(STRING_TO_ARRAY(str, ','))[N] - SQL Server（2016+）：直接
STRING_SPLIT(str, ',')，返回带value列的结果集 - Oracle：用
REGEXP_SUBSTR(str, '[^,]+', 1, N)配合CONNECT BY生成行 - 只是临时解析一两个字段？导出后用 Python 的
str.split()或 awk 更快更稳
最易被忽略的一点：在 WHERE 子句里滥用 SUBSTRING_INDEX 会导致索引失效——它让字段变成表达式，优化器无法走索引。真要查分隔字段，优先考虑规范化建模或生成虚拟列加索引。
