在XML数据处理中，XPath是用于在文档树中定位节点的核心语言。当我们需要从某个特定节点出发，按照节点之间的树形关系去查找其他节点时，单纯使用斜杠路径往往不够灵活。XPath提供的“轴（axis）”机制，正是用来明确指定节点之间相对方向关系的工具。通过轴，我们可以清晰地表达“取当前节点的子节点”“取父节点”“取后面的所有兄弟节点”等语义。
什么是XPath中的轴
XPath轴定义了上下文节点与所要选取节点之间的树状关系方向。每一个轴都有一个名称，后面跟着双冒号（::）以及节点测试，基本语法为“轴名称::节点测试”。例如，child::book表示选取上下文节点的所有名为book的子元素节点。轴将节点树中的导航路径抽象为十几种固定方向，使查询语句不再依赖绝对层级。
常见的轴包括child（子节点）、parent（父节点）、self（自身）、ancestor（祖先）、descendant（后代）、following-sibling（后续兄弟）、preceding-sibling（前序兄弟）等。在SQL Server的XPath实现中，这些轴可用于OPENXML函数的模式定义，或是在XQuery表达式里对XML类型列进行精准提取。理解轴的含义，是写出健壮XML查询的前提。
轴的语法与缩写形式
完整轴语法虽然清晰，但日常使用中大多有缩写。比如child轴可以省略，直接写book等价于child::book；parent轴缩写为单个句点加句点..；self轴缩写为单句点.；attribute轴缩写为@符号。掌握缩写能提升表达式可读性，同时减少手写错误。
下面给出一个使用完整轴语法的XPath示例，用于从一个书籍目录中选取当前节点之后的所有兄弟章节标题：
<root> <chapter id="1">引言</chapter> <chapter id="2">基础</chapter> <chapter id="3">进阶</chapter> </root> <!-- 对应XPath表达式 --> <!-- following-sibling::chapter -->
如果上下文节点是id为2的chapter，上述表达式会选中id为3的chapter节点。若使用缩写则写为following-sibling::chapter，没有更短的纯符号缩写，但语义一目了然。在MSSQL中配合OPENXML使用时，可在行集映射里用类似路径指定字段来源。
在SQL Server中运用轴查询XML
SQL Server支持将XML作为原生数据类型存储，并允许通过XQuery方法（如query()、value()）执行带轴的XPath。假设有一张表存放产品配置XML，我们想提取某个节点下的所有子元素名称，就可以利用descendant轴。
以下示例展示如何在T-SQL里用descendant轴获取深层节点：
DECLARE @x XML = '
<product>
<meta>
<name>Widget</name>
<spec>
<weight>10</weight>
<color>blue</color>
</spec>
</meta>
</product>';
SELECT
c.value('local-name(.)', 'NVARCHAR(50)') AS NodeName
FROM @x.nodes('//product/meta/descendant::*') AS T(c);
这段代码中，descendant::*从meta节点出发选中其所有后代元素，包括spec及其内部的weight与color。相比写死spec/weight等路径，轴让结构变更时查询仍有效。不过需注意，过度使用descendant可能遍历整棵子树，在超大XML上会有性能开销，应当结合具体层级用child轴限定。
轴的选用策略与常见误区
实际书写时，不少人会混淆following与following-sibling。following轴包含文档中当前节点之后的所有节点，不论层级；而following-sibling仅限同一父级下的后续兄弟。若只想横向遍历兄弟，误用following会抓到无关子孙节点，造成数据错误。
另一个误区是滥用parent轴回跳。虽然..能回到上层，但在已明确结构的查询中，从根重写绝对路径往往比反复上下导航更易懂。建议在动态结构或递归处理时使用轴，在固定报表查询中优先简明路径。通过合理指定轴，XPath查询既能精准定位，又能适应XML结构演化。
XPathXML_axisnode_selection修改时间：2026-08-07 16:30:26