游标不适合MySQL字符串分割，因其逐行处理性能差、无法预知迭代次数且易锁表；应优先用SUBSTRING_INDEX配合序号表或临时表+自定义函数的集合化方案。

MySQL 存储过程中用游标做字符串切割转行，不是好主意——游标在 MySQL 中性能差、无法提前预知迭代次数、还容易锁表。真要拆分字符串，优先走集合化思路，别碰游标。

为什么不用游标处理字符串分割

游标本质是逐行模拟循环，在 MySQL 里开销远高于集合操作：help_topic 表或自建序号表能一次性生成所有索引位置，而游标每次 fetch 都触发一次内部查询+状态维护；更关键的是，你无法在游标声明前知道字符串要拆成几项（除非先算长度再建游标，那又绕回 LENGTH() + REPLACE() 那套逻辑）；另外，游标默认只读、不可回滚，调试时修改中间结果极麻烦。

SUBSTRING_INDEX + 序号表才是可靠方案

核心是构造一个从 0 开始的连续整数序列，用来控制 SUBSTRING_INDEX 的 count 参数。MySQL 没有原生 generate_series，但可以借 mysql.help_topic（最多 701 行）或自己建一张 numbers 表：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 建表语句：

  CREATE TABLE numbers (n INT PRIMARY KEY); INSERT INTO numbers VALUES (0),(1),(2),(3),...,(999);

• 拆分逻辑：

  SELECT 
    t.id,
    SUBSTRING_INDEX(SUBSTRING_INDEX(t.tags, ',', n.n + 1), ',', -1) AS tag
  FROM your_table t
  JOIN numbers n ON n.n < LENGTH(t.tags) - LENGTH(REPLACE(t.tags, ',', '')) + 1
  WHERE t.tags IS NOT NULL;

• 注意 n.n 是因为 <code>SUBSTRING_INDEX(..., ',', 1) 取第一个元素，索引从 1 开始，但 numbers 从 0 起更易对齐

存储过程封装时避开游标，改用临时表+函数组合

如果必须封装成存储过程（比如给业务方提供统一接口），推荐用已有的 func_split_TotalLength 和 func_split 配合临时表，而不是游标：

• 先调 func_split_TotalLength('a,b,c', ',') 得到 3
• 用 WHILE 循环插入（比游标轻量得多）：

  SET i = 1;
  WHILE i <= cnt DO
    INSERT INTO tmp_result VALUES (func_split('a,b,c', ',', i));
    SET i = i + 1;
  END WHILE;

• 临时表名必须显式 DROP，否则并发调用会冲突；建议加前缀或用连接 ID 区分
• 不支持在函数中直接调用存储过程，所以 splitString 这类过程不能嵌套进函数里

边界情况和容易踩的坑

空字符串、全分隔符、NULL 值、超长字段这四类最常出错：

• SUBSTRING_INDEX('', ',', 1) 返回空字符串，不是 NULL，需用 TRIM() 判断是否有效
• 'a,,b' 经 LENGTH() - REPLACE() 计算得 2 个逗号，但实际拆出 3 项（中间空项），若业务不允许空值，得加 HAVING tag != ''
• help_topic 最大 help_topic_id 是 701，拆超过 701 项的字符串会截断，必须换自建 numbers 表
• varchar(1000) 函数参数限制，传入超长字符串会被静默截断，建议在调用前用 CHAR_LENGTH() 校验

真正难的不是写出来，而是想清楚：这个拆分结果会不会被用于 JOIN 或子查询？有没有排序依赖？要不要去重？这些逻辑一旦混进存储过程，就很难被外部控制或测试。