SQL Server用STRING_SPLIT()最省事但无序，需ROW_NUMBER()加序号；MySQL靠JSON_TABLE()脆弱，建议应用层处理；PostgreSQL用string_to_array()+unnest()WITH ORDINALITY最稳；跨库应避免硬编码，优先应用层拆分。
SQL Server 里用 STRING_SPLIT() 最省事
SQL Server 2016+ 直接支持 STRING_SPLIT()，不用手写循环或递归。它返回带 value 列的单列结果集，key 不提供顺序保证——这点常被忽略，导致后续 JOIN 或排序出错。
常见错误是直接 SELECT * FROM STRING_SPLIT('a,b,c', ',') 后就以为顺序和输入一致。实际顺序不确定，尤其在并行执行时更明显。需要显式加序号：
SELECT value, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn
FROM STRING_SPLIT('apple,banana,cherry', ',');注意：STRING_SPLIT() 不处理空元素（如 'a,,c' 中间空串会被跳过），也不支持多字符分隔符。
MySQL 没原生函数，得靠 JSON_TABLE() 或自定义函数
MySQL 8.0+ 可用 JSON_TABLE() 拆分，前提是先把字符串转成 JSON 数组格式。比如把 'x,y,z' 变成 ["x","y","z"]，再解析：
SELECT jt.val
FROM JSON_TABLE(
CONCAT('["', REPLACE('x,y,z', ',', '","'), '"]'),
'$[*]' COLUMNS (val VARCHAR(100) PATH '$')
) AS jt;这个写法脆弱：字符串含引号或反斜杠会破坏 JSON 结构；逗号在数据里（如 'a,b,"c,d"'）更没法应对。真正生产环境建议在应用层拆分，或用存储过程封装一个带边界检查的循环解析逻辑。
如果必须用存储过程，别用 REPEAT...UNTIL 配 SUBSTRING_INDEX() 做多次截取——性能差且无法处理嵌套或转义。优先考虑提前在应用侧处理，数据库只存规范化的行数据。
PostgreSQL 用 string_to_array() + unnest()
string_to_array() 返回数组，unnest() 展开成行，组合起来最稳：
SELECT unnest(string_to_array('one,two,three', ',')) AS item;它保留空元素（string_to_array('a,,c', ',') 生成 {'a','','c'}），也支持多字符分隔符（用正则时换 regexp_split_to_array()）。但注意：unnest() 不带序号，要加序号得套一层 WITH ORDINALITY：
SELECT item, ord
FROM unnest(string_to_array('a,b,c', ',')) WITH ORDINALITY AS t(item, ord);这个 ord 是真实顺序，不会因查询计划改变，比 SQL Server 的 ROW_NUMBER() 更可靠。
跨数据库兼容方案？别硬扛，换思路
试图写一个“一次编写、到处运行”的拆分存储过程，基本等于给自己埋坑。不同数据库对字符串处理的支持差异太大：Oracle 用 REGEXP_SUBSTR() 配层级查询，SQLite 几乎没选项，只能靠应用层或扩展函数。
真正可行的做法是：把拆分逻辑从数据库移出去。入库前由应用代码（Python/Java/Node.js）完成解析，插入多行；或者用中间表存原始字符串 + 拆分状态标记，定时任务异步处理。数据库不是万能胶，强行在 SQL 里做文本解析，容易让查询变慢、难以调试、上线后才发现边界 case 失效。
最常被忽略的一点：拆分后的数据是否真需要作为结果集返回？还是只需要计数、去重、匹配？很多时候用 LIKE '%term%' 或全文索引就能绕过拆分需求——先确认业务本质，再决定要不要动存储过程。
