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 的严格性、中间结果膨胀这三点，任何一个没兜住都会让统计结果出错且难以排查。
