SPLIT_PART是PostgreSQL中专为固定格式、已知分隔符位置设计的轻量级字符串定位工具，不生成数组、无容错清洗能力；其position参数必须从1开始且不能为0，索引越界返回空字符串而非报错，不支持正则分隔符。
SPLIT_PART 在 PostgreSQL 中不是“提取字段”的通用方案，而是专为固定格式、已知分隔符位置的字符串设计的轻量级定位工具——它不生成数组，也不做容错清洗，用错场景反而会让查询逻辑更难维护。
为什么 SPLIT_PART 比 SUBSTRING 更安全可靠
当你明确知道目标值总在第 N 个分隔符之后（比如日志里 timestamp|level|message 的第二段永远是日志级别），SPLIT_PART 就比靠 POSITION + SUBSTRING 手动算偏移更稳：
-
SUBSTRING容易因空格、缺失字段或嵌套分隔符崩掉，而SPLIT_PART对空片段有明确定义（返回''，不是NULL） - 不需要写
LENGTH、STRPOS套娃，语义直给：我要第 3 段，就写3 - 性能上无正则开销，纯字符串扫描，对百万行日志列做投影很轻量
SPLIT_PART 的 position 参数必须从 1 开始，且不能为 0
这是最容易栽跟头的地方。MySQL 的 SUBSTRING_INDEX 支持负数倒序取，但 SPLIT_PART 不支持 -1 表示末尾——它只认正整数索引，而且 0 会直接报错 INVALID_INDEX_OF_ZERO：
- 要取最后一个字段？得先用
array_length(string_to_array(str, delim), 1)算长度，再传进去——别硬凑SPLIT_PART(str, delim, -1)，那会失败 - 索引超出范围（比如
SPLIT_PART('a,b', ',', 5)）不会报错，但返回空字符串''，容易和真实空值混淆 - 分隔符不能为空：
SPLIT_PART('abc', '', 1)抛ERROR: zero-length delimiter
嵌套调用 SPLIT_PART 处理多层结构很常见，但要注意分隔符一致性
比如解析形如 user#role:admin,group:dev 的字段，需要两次 SPLIT_PART：
SELECT SPLIT_PART(user_profile, '#', 1) AS user_id, SPLIT_PART(SPLIT_PART(user_profile, '#', 2), ':', 1) AS role_key, SPLIT_PART(SPLIT_PART(user_profile, '#', 2), ':', 2) AS role_value FROM users;
这里的关键约束是：内层 SPLIT_PART 必须确保返回的是单一段（比如 'role:admin'），否则外层按 ':' 切可能切歪。如果第二段本身含冒号（如 role:admin:v2），这个写法就不可靠——此时该换 REGEXP_MATCHES 或先标准化字符串。
当分隔符不固定时，SPLIT_PART 就该让位了
SPLIT_PART 只接受字面量分隔符，不支持正则。遇到以下情况，别硬撑：
- 字段间可能是
','或', '（逗号+空格）→ 先用REGEXP_REPLACE(str, ',\s*', ',')归一化 - 想按“一个或多个空白”拆 → 改用
regexp_split_to_array(str, '\s+')，再取下标 - 需要保留所有分割结果做遍历 → 直接上
string_to_array(str, ',')，它能处理连续分隔符（'a,,c'→{'a','','c'}）
真正麻烦的从来不是怎么切，而是切完之后怎么判断哪一段是有效数据——SPLIT_PART 给你的是“第 N 块”，不是“叫 name 的那块”。如果源格式本身不稳定，函数再快也没用。
