XQuery与SQL本质不同：SQL处理二维表结构，依赖Schema和JOIN；XQuery处理树状XML，用路径动态导航、支持可变结构和XML构造。二者数据模型、语法（FLWOR vs SELECT-FROM-WHERE）、类型检查（静态编译期）及适用场景截然不同。
XQuery 和 SQL 看起来都是“查数据的语言”，但它们根本不是同一类工具——SQL 是管结构化表格的“数据库管理员”，XQuery 是处理 XML 树形结构的“内容雕刻师”。用错场景，轻则查不到东西，重则写出无法维护、性能崩塌的查询。
数据模型决定一切：表 vs 节点树
SQL 的世界是二维的：SELECT * FROM users 返回的是行和列组成的矩形结果集，每列类型固定、每行结构一致。它依赖严格 Schema，靠 JOIN 拼接关联表，靠事务保障一致性。
XQuery 的世界是树状的：一个 XML 文档被看作由 element、attribute、text 等节点构成的层级结构。它不预设“有多少列”，而是用路径（如 /bookstore/book/title）动态钻取任意深度的节点，天然支持可变结构（比如有的 <book> 有 <isbn>，有的没有）。
- SQL 查询失败常因
column not found或type mismatch—— Schema 不匹配就报错 - XQuery 查询失败更可能是路径写错（如漏掉命名空间前缀）、节点不存在却没做空值防护，或类型推导失败（见下文静态类型部分）
语法风格差异：FLWOR vs SELECT-FROM-WHERE
SQL 的核心动词是 SELECT、FROM、WHERE，逻辑顺序接近自然语言；XQuery 的核心结构是 FLWOR（for, let, where, order by, return），本质是函数式+声明式混合体，更像一段“数据流管道”：
for $b in /bookstore/book
where $b/price > 30
order by $b/title
return <expensive>{ $b/title/text() }</expensive>-
for类似 SQL 的FROM，但可遍历任意节点序列（不止一张表） -
let可绑定中间变量（类似 CTE 或子查询别名），但作用域更灵活 -
return必须显式构造输出 —— 它能生成 XML 元素、文本、甚至嵌套结构，不局限于“返回字段” - 没有隐式
DISTINCT或自动去重；重复节点需手动用distinct-values()
SQL/XML 和 XQuery 在数据库里怎么共存？
在 SQL Server、DB2、Oracle 等支持 XML 字段的数据库中，你其实有三种混用方式：
- 纯 SQL + SQL/XML 函数：用
XMLELEMENT、XMLATTRIBUTES把关系数据“包装成 XML”——适合简单封装，但逻辑耦合强、难复用 - SQL 中调用 XQuery：用
XMLQUERY（返回单个 XML 值）或XMLTABLE（把 XML 拆成关系表）——这是最常用、最务实的桥接方式 - 独立 XQuery 查询：直接对 XML 列执行
XQUERY '...'——适合复杂转换，但无法直接 JOIN 其他表，需配合XMLTABLE回填
典型陷阱：XMLQUERY 默认只返回第一个匹配节点，若路径可能命中多个节点却没加 [1] 或没用 XMLTABLE 展开，就会静默丢数据。
静态类型检查：XQuery 编译期就卡你脖子
SQL Server 中的 XQuery 是静态类型语言——不是运行时报错，而是在编译阶段就拒绝非法表达式。例如：
-
/book/price + "abc"直接编译失败：字符串不能和数字相加 -
/book/author/text()若 XML Schema 规定author是xs:string?（可选字符串），那这个表达式推导出的类型就是xs:string?；若后续用它参与concat()却没做空值判断，也可能报错 - 非类型化 XML（没绑定 Schema）会默认转为
xs:string比较，导致/book/id = "123"成功，但/book/id > 100失败（字符串比较 vs 数值比较）
这意味着：不定义 XML Schema，XQuery 就像蒙眼开车；定义了 Schema，又得确保所有路径都真实存在——否则静态推导会认定“这路径永远返回空”，整个分支被优化掉。
真正难的不是写对一句 XQuery，而是判断该用 SQL 还是 XQuery，以及在哪一层做转换。XML 存在数据库里，不等于就要用 XQuery 查；很多时候，先用 SQL 提取出 XML 列，再用应用层解析，比硬塞进数据库 XQuery 引擎更可控、更易调试。
