MySQL 5.7 拆分字符串应使用 SUBSTRING_INDEX 配合从 0 开始的序号表，避免游标；需控制索引边界、预处理空格、显式处理 NULL，并确保序号表覆盖足够长度。
用 SUBSTRING_INDEX + 序号表代替游标
MySQL 5.7 不支持递归 CTE，也没有原生 SPLIT 函数，硬写游标拆字符串是性能黑洞——每次 FETCH 都触发一次内部状态维护，且无法预知循环次数。真实可行的路只有一条：构造一个整数序列（numbers 表），配合 SUBSTRING_INDEX 按位置取值。
常见错误现象：SELECT SUBSTRING_INDEX('a,b,c', ',', n.n+1) 返回空或重复首项，本质是没控制好索引边界。
-
numbers表必须从0开始，且最大值 ≥ 字符串中分隔符个数（可用LENGTH(str)-LENGTH(REPLACE(str,delim,''))+1算出） - WHERE 条件里必须限制
n.n ，否则会返回空字符串或重复最后一项 - 不要用
help_topic表凑数——它只有 701 行，一旦字段含超 700 个逗号就截断
SPLIT_STR 自定义函数要小心 position 起始值
你写的 SPLIT_STR(str, delim, position) 函数，如果按 1 开始计数（比如 SPLIT_STR('a,b,c', ',', 2) 返回 b），那在 JOIN 序号表时就得让 n.n + 1 对齐；但如果函数内部用的是 0 起始逻辑（如某些旧版实现），结果就全错。
典型翻车点：SUBSTRING_INDEX(SUBSTRING_INDEX(str, delim, n.n), delim, -1) 在 n.n = 0 时返回空，因为 SUBSTRING_INDEX(str, delim, 0) 恒为空字符串。
- 推荐统一用 1 起始：函数体写成
RETURN SUBSTRING_INDEX(SUBSTRING_INDEX(str, delim, position), delim, -1) - 调用时传
n.n + 1，确保序号表n从 0 起，语义清晰不绕 - 对空字符串或 NULL 输入，函数需显式判断并返回 NULL，避免
SUBSTRING_INDEX('', ',', 1)返回空串干扰去重
存储过程里别直接写游标循环拆字符串
真要封装成存储过程（比如给 Java 服务提供统一接口），游标仍是下策。更轻量的做法是：先算总数，再用 WHILE 插入临时表。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
容易踩的坑：INSERT INTO tmp_result SELECT SPLIT_STR(...) 看似简洁，但 MySQL 5.7 不允许在函数中调用存储过程，反过来也不行——所以不能把 SPLIT_STR 套进更复杂的逻辑里当黑盒用。
- 临时表名必须带会话唯一标识，例如
tmp_split_，否则并发调用会冲突 -
WHILE循环前必须DROP TEMPORARY TABLE IF EXISTS，否则第二次调用报错“表已存在” - 别忘了
SET i = 1初始化，否则变量未声明直接参与比较，结果不可控
边界情况比想象中多：空串、NULL、无分隔符、嵌套空格
业务数据从来不是理想化的 a,b,c。真实字段可能是 ' , a , b ,, c '，甚至全是空格加一个逗号。
这时候 SPLIT_SIZE 函数如果没 trim 就直接算 LENGTH，结果会多出 2～3 项；而 SUBSTRING_INDEX 对前后空格不敏感，但取出来就是带空格的字符串，后续 JOIN 或 IN 匹配全失效。
-
SPLIT_STR函数内部建议加TRIM：比如TRIM(BOTH ' ' FROM SUBSTRING_INDEX(...)) - 拆分后想过滤空值？不能只靠
WHERE tag != ''，得写成WHERE TRIM(tag) != '' - 如果原始字段可能为 NULL，JOIN 序号表前必须加
WHERE t.tags IS NOT NULL，否则整行记录消失
实际最常被忽略的，是序号表的覆盖范围和空格清洗——这两点不出问题时一切正常，一出就是线上数据少一半、匹配全失败，还很难复现。
