parsename 不能安全解析 ipv4 地址，因其设计仅用于四段式 sql server 对象名称（如 db.schema.table.column），从右向左解析且不校验 ip 合法性；遇非法段、前导零、ipv6 或带端口地址即失效，应改用 string_split + row_number() 配合校验。
PARSENAME 不是为解析 IP 地址设计的，强行用它处理 192.168.1.1 会出错或返回意外结果；它只适用于四段式、以点分隔的 SQL Server 对象名称（如 db.schema.table.column），且从右往左数段。
为什么 PARSENAME 不能安全解析 IPv4 地址
PARSENAME 的语义是“解析对象名称”，内部逻辑假设输入是合法的四部分对象标识符，且每部分不含特殊字符（如空格、括号、中划线）。IP 地址虽然也是点分四段，但存在几个硬伤：
- 它把
192.168.1.1当作[1].[1].[168].[192]反向解析，PARSENAME('192.168.1.1', 1)返回1，PARSENAME('192.168.1.1', 4)返回192—— 表面看能用，但这是巧合，不是设计用途 - 遇到非法段（如
192.168.256.1）或带前导零（192.168.01.1）时，函数不校验，照常返回字符串，掩盖数据问题 - IPv6、带端口的地址（
192.168.1.1:8080）、主机名（server01.prod.local）会直接失效——PARSENAME最多只认 4 段，超出部分被截断或返回NULL
正确解析对象名称时的使用边界
当且仅当你处理的是标准 SQL Server 四层对象引用（如 MyDB.dbo.Users.ID）时，PARSENAME 才可靠。它的参数是 object_name 和 part_number（1=最右段，4=最左段），且对大小写不敏感、自动忽略方括号。
-
PARSENAME('[MyDB].[dbo].[Users]', 1)→Users -
PARSENAME('MyDB.dbo.Users', 2)→dbo -
PARSENAME('server.db.schema.obj', 4)→server（仅当启用了四部分名称支持且链接服务器配置正确） - 如果段数不足 4，缺失段返回
NULL；例如PARSENAME('Users', 2)→NULL
替代方案：用 STRING_SPLIT + ROW_NUMBER 解析 IP 地址
SQL Server 2016+ 推荐用 STRING_SPLIT 配合 ROW_NUMBER() 实现可控、可验证的 IP 解析。它不依赖段数固定，还能加校验逻辑。
SELECT
ip,
MAX(CASE WHEN rn = 1 THEN value END) AS octet1,
MAX(CASE WHEN rn = 2 THEN value END) AS octet2,
MAX(CASE WHEN rn = 3 THEN value END) AS octet3,
MAX(CASE WHEN rn = 4 THEN value END) AS octet4
FROM (
SELECT
'192.168.1.1' AS ip,
value,
ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS rn
FROM STRING_SPLIT('192.168.1.1', '.')
) t
GROUP BY ip;
这样能明确控制每一段，并在外部加 ISNUMERIC 和范围检查（如 CONVERT(INT, value) BETWEEN 0 AND 255），避免无效 IP 被误解析。
容易被忽略的兼容性细节
PARSENAME 在所有 SQL Server 版本中行为一致，但它对输入不做任何标准化处理：含空格的名称（db . schema . table）会返回 NULL；含反斜杠或冒号的路径（\servershare）完全不适用；而 STRING_SPLIT 默认不保证顺序（SQL Server 2022 开始支持 ordinal 参数），老版本必须用 ROW_NUMBER() 显式排序。
真正要解析网络地址，别绕弯子——交给应用层或 CLR 函数更稳妥；在 T-SQL 里硬解，就老实用 STRING_SPLIT + 显式序号 + 边界校验。
