MySQL用SUBSTRING_INDEX配合help_topic表实现逗号字段炸裂，本质是按位置切分字符串；最多炸裂行数受限于help_topic记录数，需注意ONLY_FULL_GROUP_BY报错、GROUP_CONCAT反向用途及性能瓶颈。

MySQL 用 SUBSTRING_INDEX + help_topic 实现逗号字段炸裂

直接炸裂逗号分隔字段，本质是“把一个字符串按位置切出多个值”，MySQL 没有原生 split 函数，得靠 SUBSTRING_INDEX 配合连续数字表模拟循环。最常用的是 mysql.help_topic 表，它自带从 0 开始的连续 help_topic_id。

关键点在于：你最多能炸出多少行，取决于 help_topic 表有多少条记录。比如它只有 500 行，那单个字段最多拆成 500 个值——超长字段会被截断，且无报错提示。

• SUBSTRING_INDEX(str, ',', n)：取第 n 个逗号左边全部内容
• SUBSTRING_INDEX(SUBSTRING_INDEX(str, ',', n), ',', -1)：取第 n 个逗号分割出的“最后一段”，即第 n 个值
• 必须用 JOIN 把原表和 help_topic 关联，且限制 b.help_topic_id 避免多余空行

炸裂后 GROUP BY 必须显式写全非聚合字段

炸裂后数据行数变多，但分组逻辑不变。如果你 SELECT 了原始表的 id、炸裂出的 value，又想按 value 统计次数，GROUP BY value 就够了；但若还选了 id，就必须写 GROUP BY id, value，否则在开启 ONLY_FULL_GROUP_BY（MySQL 5.7+ 默认开）时直接报错 ERROR 1055。

• 错误写法：SELECT id, SUBSTRING_INDEX(...) AS val, COUNT(*) FROM t JOIN help_topic ... GROUP BY val —— id 既没聚合也没出现在 GROUP BY 中
• 正确写法：SELECT val, COUNT(*) FROM (...) AS exploded GROUP BY val，或把 id 放进子查询再聚合
• 别指望 GROUP BY val 自动“保留原记录上下文”，炸裂后每行是独立新记录

GROUP_CONCAT 是反向操作，别和炸裂混淆

有人看到“逗号分割”就下意识想用 GROUP_CONCAT，但它干的是相反的事：把多行合并成一行逗号串。它不能帮你把一个字段拆开，只适合炸裂后的逆向汇总（比如炸裂统计完，再按某维度把结果拼回去）。

• GROUP_CONCAT(val ORDER BY val SEPARATOR '|') 可用于后续展示，但不参与炸裂流程
• 它默认长度限制 1024 字符，超长会被截断，需提前设 SET SESSION group_concat_max_len = 1000000
• 和炸裂无关，强行套用只会让逻辑绕弯，还容易因长度截断导致统计遗漏

炸裂性能差，大数据量务必加临时表或改用应用层处理

每次炸裂都要 JOIN help_topic，如果原表 10 万行、平均每个字段含 5 个值，就会生成 50 万行中间结果，JOIN 和 GROUP BY 都会明显变慢。更糟的是 help_topic 表大小固定，无法扩展。

• 替代方案：导出数据到 Python/Java，用 str.split(',') 处理后再批量 INSERT 回库
• 临时表优化：先炸裂写入 CREATE TEMPORARY TABLE exploded AS SELECT ...，再对临时表 GROUP BY，避免重复计算
• 真正长期方案：修改表结构，把逗号字段范式化为关联子表，炸裂需求就变成普通 JOIN 查询

炸裂是权宜之计，help_topic_id 的上限、ONLY_FULL_GROUP_BY 的严格性、中间结果膨胀这三点，任何一个没兜住都会让统计结果出错且难以排查。