PARSENAME仅支持最多4段点分隔字符串，从右向左按1~4编号返回对应部分，专为解析数据库对象名（如server.db.schema.object）设计，不适用于通用字符串分割。
PARSENAME 只能处理最多4段的点号字符串
PARSENAME 本质是为解析对象名（如 db.schema.table.column）设计的，不是通用字符串分割函数。它**只接受最多4个点分隔的部分**，超出部分直接被截断或返回 NULL。比如 PARSENAME('a.b.c.d.e', 1) 返回 NULL，而不是 e —— 因为它从右往左数第1段时，已忽略最左边的 a.。
常见错误现象：PARSENAME('server.db.owner.table', 5) 不报错但返回 NULL；PARSENAME('x.y', 3) 同样返回 NULL，而非空字符串。
- 可用段数固定为 1–4，对应从右往左的位置：1=最右段，4=最左段
- 输入字符串中**不能含方括号、引号等对象名特殊字符**，否则解析可能意外失败（如
PARSENAME('[my.db].schema.table', 1)返回table，但[my.db]被当作一个整体段，实际只算3段） - 空段不被支持：
PARSENAME('a..b', 2)返回NULL，不是空字符串
替代方案：用 STRING_SPLIT + ROW_NUMBER 处理任意长度点号串
当需要拆分超过4段、或需稳定获取第N段（无论左右顺序）时，STRING_SPLIT 是更可靠的选择（SQL Server 2016+）。它不预设段数上限，且能配合 ROW_NUMBER() 精确定位。
例如提取 'a.b.c.d.e.f' 的第3段（从左往右）：
SELECT value
FROM (
SELECT value, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn
FROM STRING_SPLIT('a.b.c.d.e.f', '.')
) t
WHERE rn = 3;注意：STRING_SPLIT 返回结果**无序保证**，必须显式加 ORDER BY（哪怕用 (SELECT NULL) 占位）才能让 ROW_NUMBER() 按原始顺序编号 —— 这是极易忽略的坑。
- SQL Server 2016 之前版本需用递归 CTE 或数字表模拟拆分
-
STRING_SPLIT会跳过空段（'a..b'拆成a、b两行），若需保留空段，得先用REPLACE预处理 - 性能上，
PARSENAME是纯函数，零开销；STRING_SPLIT是表值函数，大数据量循环调用时要注意执行计划膨胀
PARSENAME 的真实适用场景：解析标准四层对象名
它最自然的用法就是逆向提取数据库对象层级，比如从完整名称中拿 schema 名或 object 名：
SELECT
PARSENAME('MyDB.dbo.Users', 4) AS [database], -- 'MyDB'
PARSENAME('MyDB.dbo.Users', 3) AS [schema], -- 'dbo'
PARSENAME('MyDB.dbo.Users', 2) AS [object], -- 'Users'
PARSENAME('MyDB.dbo.Users', 1) AS [column]; -- NULL（无列名）这种场景下，输入格式可控、段数明确，PARSENAME 简洁安全。但如果用户传入的是业务数据（如 IP 地址 '192.168.1.1' 或域名 'api.v1.example.com'），就别硬套 —— 尤其后者常超4段，且语义上“最右段”未必是你想要的顶级域。
- IP 地址建议用
PARSENAME仅限 IPv4 且确认格式严格（xxx.xxx.xxx.xxx），否则'127.0.0.1:8080'会出错 - 对域名，优先考虑
STRING_SPLIT+COUNT(*)判断层级再取值，比依赖PARSENAME(..., 1)更健壮 - 所有用法都应加
ISNULL或NULLIF包裹，防止上游数据异常导致整行NULL
为什么不能把 PARSENAME 当字符串工具用
根本原因在于它的实现逻辑：SQL Server 内部把它当作「对象标识符解析器」，会尝试验证每段是否符合标识符命名规则（比如不能以数字开头、不能含非法字符）。一旦某段违规，整个函数就静默返回 NULL，不报错也不提示。
例如：PARSENAME('a.123.b', 2) 返回 NULL（因为 123 不是合法标识符），而 PARSENAME('a.[123].b', 2) 才返回 123 —— 但这已经脱离了“字符串拆分”的本意，变成在和 SQL 标识符规则博弈。
- 业务字符串几乎不可能满足 SQL 标识符约束，强行用
PARSENAME就等于把数据清洗责任甩给函数本身 - 调试困难：返回
NULL时你无法知道是段数超限、含非法字符，还是输入为空 - 可读性差：看到
PARSENAME(@input, 2)的人，第一反应是“这是在取 schema 名”，而不是“这是在取第二个点分段”
真正要拆点号串，就老实用 STRING_SPLIT 或自定义拆分函数。把 PARSENAME 留给它该待的地方：解析 database.schema.object.column。
