MySQL 8.0+ 推荐用 JSON_TABLE 拆分逗号字符串，需先将字符串转为合法 JSON 数组格式如 '["1","2","5"]'；PostgreSQL 用 string_to_array + UNNEST 并配合 NULLIF 过滤空值；SQL Server 用 STRING_SPLIT 需处理 NULL 输入及无序问题；通用建议是避免 SQL 层硬拆，优先上游展开为关联表或预拆至中间表。
MySQL 8.0+ 用 JSON_TABLE 拆分最稳
直接把逗号字符串转成行集合，JSON_TABLE 是目前 MySQL 原生最可靠的方式。它不依赖自定义函数，也不怕 ID 含空格或引号（只要先转成合法 JSON 数组）。
常见错误是直接对原始字符串调用 JSON_TABLE，结果报错 Invalid JSON text —— 必须先用 REPLACE 和拼接补上方括号和引号：
- 原始字段
id_list值为"1,2,5"，要先处理成'["1","2","5"]' - SQL 示例：
SELECT t.id, jt.value AS single_id FROM your_table t, JSON_TABLE( CONCAT('["', REPLACE(t.id_list, ',', '","'), '"]'), '$[*]' COLUMNS (value VARCHAR(50) PATH '$') ) AS jt; - 注意：如果原始 ID 本身含双引号或反斜杠，需额外
REPLACE转义，否则 JSON 解析失败
PostgreSQL 用 string_to_array + UNNEST
PostgreSQL 原生支持数组类型，拆分干净利落。但容易忽略两点：空字符串处理和 NULL 输入。
典型场景是日志表里存了 user_ids TEXT 字段，值为 '101,102,'（末尾带逗号），直接 UNNEST(string_to_array(...)) 会多出一个空行。
- 安全写法：用
NULLIF过滤空元素：SELECT id, NULLIF(elem, '') AS single_id FROM your_table, UNNEST(string_to_array(id_list, ',')) AS elem WHERE NULLIF(elem, '') IS NOT NULL;
- 如果
id_list可能为NULL，string_to_array(NULL, ',')返回NULL，UNNEST不报错但不产出行 —— 符合预期，无需额外判空 - 性能提示：该组合在大表上执行时，建议给
id_list加函数索引（如CREATE INDEX idx_id_list_arr ON your_table USING GIN ((string_to_array(id_list, ',')));）
SQL Server 用 STRING_SPLIT 注意兼容性陷阱
STRING_SPLIT 在 SQL Server 2016+ 可用，但它返回的行**无序且无序号**，如果业务依赖原始顺序（比如“第一个ID代表主负责人”），就不能直接用。
另一个坑是：当输入字符串为 NULL 或空串时，STRING_SPLIT('', ',') 返回空结果集，而 STRING_SPLIT(NULL, ',') 报错 Argument data type NULL is invalid for argument 1 of string_split function.
- 必须提前过滤或转换：
SELECT t.id, s.value AS single_id FROM your_table t CROSS APPLY STRING_SPLIT(ISNULL(NULLIF(t.id_list, ''), ' '), ',') s WHERE s.value != ' ';
- 若需保序，得靠外部应用层处理，或在拆分前加自增序号列（需借助
ROW_NUMBER()配合临时表） - SQL Server 2022 支持
STRING_SPLIT的enable_ordinal参数，但老版本无法回退
通用方案：避免在 SQL 层硬拆，优先考虑上游清洗
所有数据库的字符串拆分本质上都是反范式操作。真正高频、大数据量的场景下，硬拆必然拖慢查询，也难加索引。
实际项目里更健壮的做法是：让写入方把 ID 列表展开成关联表（如 order_id + item_id），而不是塞进一个 TEXT 字段。
- 如果已有脏数据且无法改表结构，可建物化视图或定时任务预拆到中间表，查时走 JOIN
- 应用层（Python/Java）拆分后再批量 INSERT，比在 SQL 里反复解析快一个数量级
- 特别警惕
LIKE '%,123,%'这类模糊匹配 —— 看似简单，实际无法走索引，且易误匹配（如匹配到1123）
拆分逻辑越靠近数据源头，后续的查询、统计、权限校验就越不容易出边界问题。
