MySQL用嵌套SUBSTRING_INDEX提取第N个逗号值，如SUBSTRING_INDEX(SUBSTRING_INDEX(str,',',N),',',-1)；PostgreSQL用SPLIT_PART(str,',',N)直接获取；二者语法不兼容，无跨库标准函数。
MySQL 用 SUBSTRING_INDEX 提取第 N 个逗号分隔值
SUBSTRING_INDEX 是 MySQL 原生函数，适合按固定分隔符提取前 N 段或倒数 N 段。它不返回数组，而是字符串，所以“拆分”其实是逐段截取。
常见错误是以为 SUBSTRING_INDEX('a,b,c', ',', 2) 能直接拿到 'b' —— 实际返回的是 'a,b'。要取中间项，得嵌套两次：
-
SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c', ',', 2), ',', -1)→'b' -
SUBSTRING_INDEX(SUBSTRING_INDEX('a,b,c', ',', 3), ',', -1)→'c' - 取第 1 个：直接
SUBSTRING_INDEX('a,b,c', ',', 1)
注意负数第二个参数表示从右往左数：SUBSTRING_INDEX('a,b,c', ',', -2) 返回 'b,c'。嵌套时内外方向要一致，否则容易错位。
PostgreSQL 用 SPLIT_PART 取指定位置的字段
SPLIT_PART 是 PostgreSQL 的标准函数，语义更直观：给定字符串、分隔符、序号（从 1 开始），直接返回对应片段。
示例：SPLIT_PART('x,y,z', ',', 2) 返回 'y'；SPLIT_PART('a,,c', ',', 2) 返回空字符串 ''（不是 NULL）。
- 序号超出范围时返回空字符串，不会报错
- 分隔符为空（
''）会报错：ERROR: zero-length delimiter - 不支持正则分隔符，如需按多个空白或逗号+空格拆，得先用
REGEXP_REPLACE标准化
如果需要把整个字符串转成数组再处理，用 STRING_TO_ARRAY('a,b,c', ',')，但注意它会保留空元素（'a,,c' → {'a','','c'}）。
跨数据库兼容性问题：没有通用“拆分函数”
MySQL 没有 SPLIT_PART，PostgreSQL 没有 SUBSTRING_INDEX，SQL 标准本身也不定义这类字符串拆分函数。想写可移植 SQL，基本不可行。
- 若必须兼容，建议在应用层拆分（如 Python 的
str.split(',')或 Java 的String.split()） - 在数据库内做，就接受方言绑定：MySQL 用嵌套
SUBSTRING_INDEX，PostgreSQL 直接用SPLIT_PART - 复杂场景（如多级嵌套、不定长字段）别硬扛在 SQL 里，容易变成难以调试的嵌套地狱
尤其注意空值和边界情况：MySQL 中 SUBSTRING_INDEX(NULL, ',', 1) 返回 NULL；PostgreSQL 中 SPLIT_PART(NULL, ',', 1) 也返回 NULL —— 行为一致，但空字符串处理逻辑不同。
为什么不能用 JOIN LATERAL 或 generate_series 模拟“逐行展开”？
有人尝试用 generate_series（PostgreSQL）或递归 CTE（MySQL 8.0+）把逗号字段“炸开”成多行，这确实可行，但属于重量级操作，仅适用于真正需要展开的场景（比如统计每个标签出现次数）。
- 简单取第 2 个值，用
SPLIT_PART或嵌套SUBSTRING_INDEX就够了，性能更好 - 用
LATERAL+UNNEST(STRING_TO_ARRAY(...))会强制物化整个数组，对大表扫描代价高 - MySQL 8.0 的递归 CTE 写法冗长，且无法在 WHERE 中提前过滤，容易拖慢查询
真正要小心的是字段里混入转义逗号（如 CSV 中的 "a,b",c），这时候所有基于简单分隔符的函数都会失效——那已经不是 SQL 层该解决的问题了。
