SQL Server视图中用.nodes()解析XML字段时少数据，根本原因是路径未匹配导致整行被过滤而非返回NULL；必须确保XML非NULL、路径精确匹配（含大小写与命名空间）、节点存在性，否则静默丢失数据。
直接用 XMLTABLE（Oracle）或 .nodes() + .value()（SQL Server）就能把 XML 字段“摊开”成标准表，不用视图也能做；但真要建视图，核心难点不在解析，而在命名空间、空节点容忍和性能边界——这些不提前处理，视图一查就报错或卡死。
SQL Server 视图里用 .nodes() 解析 XML 字段时，为什么总少数据？
常见现象是视图返回行数远少于预期，甚至全为 NULL。根本原因是 .nodes() 路径没匹配到任何节点，它直接跳过整行，而不是返回 NULL 行。
- 必须确认 XML 字段非 NULL 且格式良构：用
WHERE xml_col IS NOT NULL AND xml_col.exist('/root') = 1过滤掉脏数据 - 路径写错不会报错，只会静默不匹配：比如实际是
<Items><Item>...</Item></Items>，却写了/root/Item—— 改成/Items/Item或加前缀/root/Items/Item - 含命名空间的 XML 必须用
WITH XMLNAMESPACES声明，默认命名空间也要显式绑定，否则所有路径失效 - 若 XML 中某节点可能缺失（如
<price>有时不存在），.value('(/Item/price)[1]', 'decimal(10,2)')会返回 NULL，但别指望它报错提醒你路径不对
Oracle 视图中 XMLTABLE 的 PATH 写法容易踩哪些坑？
XMLTABLE 看似简单，但 PATH 表达式错一个字符，结果就是空集，而且没有任何提示。
-
PATH必须从当前上下文节点开始写：比如XMLTABLE('/DEAL_BASIC/USER_DEAL_INFO' ... COLUMNS USER_DEAL_ID VARCHAR2(50) PATH '/USER_DEAL_INFO/USER_DEAL_ID')，第二个/USER_DEAL_INFO是多余的，应写成PATH 'USER_DEAL_ID' - 文本节点必须显式加
text()：写PATH 'USER_DEAL_ID'可能返回带标签的 XML 片段，要写PATH 'USER_DEAL_ID/text()'才得纯字符串值 - 如果 XML 含默认命名空间（
xmlns="http://xxx"），XMLTABLE的PASSING部分必须用XMLNAMESPACES绑定，否则整个查询返回空 - 日期类字段（如
DEAL_INURE_TIME）用VARCHAR2提取后再TO_DATE()转换更安全，直接声明DATE类型容易因格式不一致报 ORA-01843
跨数据库建通用视图时，OPENXML 和 nodes() 哪个更可控？
OPENXML 在 SQL Server 里能复用句柄、支持复杂映射，但绝不能放进视图——它依赖 sp_xml_preparedocument 和 sp_xml_removedocument 的配对调用，而视图不允许执行存储过程。
- 视图只能用纯函数式方法：
.nodes()+.value()是唯一安全选择；OPENXML只能用于存储过程或即席查询 - PostgreSQL 没有
OPENXML，靠xpath()+UNNEST()，但返回的是数组，视图里必须用CROSS JOIN LATERAL展开，否则类型不匹配 - MySQL 8.0+ 有
EXTRACTVALUE()（已弃用）和XMLQUERY()，但功能弱、不支持命名空间，实际项目中基本绕开，改用应用层解析 - 所有数据库里，XML 字段一旦超过 1MB，视图查询响应就会明显变慢；建议在源表上对 XML 字段建 XML 索引（SQL Server）或函数索引（Oracle），否则每次解析都是全量扫描
最常被忽略的是：XML 字段里混入未转义的 &、、<code>" 会导致解析直接失败，而错误只在视图首次使用时暴露——不是定义时报错，而是 SELECT * FROM your_view 时才崩。上线前务必用 TRY_CAST(xml_col AS XML)（SQL Server）或 XMLTYPE(xml_col) IS NOT NULL（Oracle）做批量校验。
