SUBSTRING_INDEX不是提取第N段，而是“切到第N个分隔符位置”：SUBSTRING_INDEX('a,b,c', ',', 2)返回'a,b'，因它截取第2个逗号左侧全部内容；要取第2段b，须嵌套SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c', ',', 2), ',', -1)。
SUBSTRING_INDEX 不是“按字符截取”，而是按分隔符做逻辑切片——想精准拿到某个字段，必须理解它不返回数组、也不提取第 N 段，只做单次“切到某位置”的操作。
为什么 SUBSTRING_INDEX('a,b,c', ',', 2) 返回 'a,b' 而不是 'b'？
因为它的语义是“从左往右找第 2 个 ,，返回它左边全部内容”，不是“取第 2 个逗号分隔的值”。SUBSTRING_INDEX 的 count 参数控制切点，不控制提取目标段。
- 要真正拿到第 2 段（即
b），必须嵌套：先切到前两段，再从结果里取最后一段：SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c', ',', 2), ',', -1) - 顺序不能反：写成
SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c', ',', -2), ',', 1)会出错——负数切法返回的是b,c，再用正数1切会得到空或错误前缀 - 如果原始字符串里分隔符少于
count次（比如'a'用SUBSTRING_INDEX('a', ',', 2)），函数直接返回原字符串，不会报错也不会截空
如何从非标准格式中提取 finalScore="65" 的数值？
这类场景常见于日志字段或拼接字符串，SUBSTRING_INDEX 可以配合两次定位完成粗粒度提取，但要注意边界字符的处理。
- 第一步：用
SUBSTRING_INDEX(str, 'finalScore="', -1)拿到65" RGID="100397278" - 第二步：对上一步结果再用
SUBSTRING_INDEX(..., '"', 1)截取第一个双引号前的内容，得到65 - 完整写法：
SUBSTRING_INDEX(SUBSTRING_INDEX(log_text, 'finalScore="', -1), '"', 1) - 注意：如果字段里存在多个
finalScore=或引号嵌套，这个方法会失效；此时应考虑应用层清洗或升级到 MySQL 8.0+ 用REGEXP_SUBSTR
在 WHERE 条件里用 SUBSTRING_INDEX(domain) 为什么慢？
因为 SUBSTRING_INDEX(email, '@', -1) 是对字段运行时计算，MySQL 无法利用索引加速，导致全表扫描。
- 现象：
WHERE SUBSTRING_INDEX(email, '@', -1) = 'gmail.com'执行计划显示type: ALL - 正确解法：新增
domain字段，在 INSERT/UPDATE 时由触发器或应用同步写入，再建索引：CREATE INDEX idx_domain ON users(domain) - 查询改写为：
WHERE domain = 'gmail.com'，响应时间从秒级降到毫秒级 - 若必须临时查，可用
email LIKE '%@gmail.com'（有索引时可走后缀优化，但不如前缀高效）
SUBSTRING_INDEX 和其他截取函数的关键区别在哪？
它唯一能处理“按分隔符定位”的需求，但代价是语义反直觉、嵌套繁琐；而 LEFT/RIGHT/SUBSTRING 都依赖固定偏移，适合结构化强的字段。
-
LEFT(email, 5)和SUBSTRING(email, 1, 5)等价，但无法应对邮箱长度不一的场景 -
SUBSTRING_INDEX(email, '@', -1)能稳定拿到域名，但不能替代正则——比如验证是否含有效 TLD，还得靠REGEXP '^[^@]+\.[^@]+$' - MySQL 8.0+ 推荐优先用
REGEXP_SUBSTR处理复杂模式，但 5.7/8.0 早期版本仍需靠SUBSTRING_INDEX套娃硬刚
最常被忽略的一点：它不校验分隔符是否存在。哪怕字段里根本没有 @，SUBSTRING_INDEX(email, '@', -1) 也会原样返回整字段——所以生产环境一定要加 email REGEXP '^[^@]+@[^@]+\.[^@]+$' 或至少 CHAR_LENGTH(SUBSTRING_INDEX(email, '@', -1)) > 0 做兜底判断。
