ExtractValue和UpdateXML是MySQL中已弃用的XML处理函数，仅支持XPath 1.0子集，不支持谓词函数、命名空间、动态路径及节点增删；推荐改用JSON函数替代。

ExtractValue 用来从 XML 字符串里取值，但只支持 XPath 1.0 且不能写表达式

ExtractValue(xml_str, xpath_expr) 返回的是字符串，不是节点集。它内部调用的是 libxml2 的 XPath 1.0 实现，不支持 //node[1] 这类位置路径以外的谓词（比如 //item[@id='100'] 可以，但 //item[position()=1] 会报错），也不支持函数调用（如 count()、string-length()）。

常见错误现象：ExtractValue('hello', '//a/text()') 返回空 —— 因为 text() 不被支持；正确写法是 '//a'，它会自动提取文本内容。

• XPath 必须是字符串字面量，不能拼接变量（即不能用 CONCAT('//', @tag) 直接传入）
• 如果匹配多个节点，只返回第一个节点的文本内容（其余被静默丢弃）
• XML 中有命名空间时，ExtractValue 完全无法处理（没提供 namespace 绑定机制）
• 遇到格式错误的 XML（如未闭合标签），函数直接返回 NULL，不会报错

UpdateXML 修改 XML 节点内容，但只能替换整个匹配节点，且不支持新增节点

UpdateXML(xml_str, xpath_expr, new_xml) 把第一个匹配到的节点替换成 new_xml 字符串。注意：它不是“修改节点内容”，而是“用新 XML 片段替换整个节点”。例如：

SELECT UpdateXML('Alice', '/root/user', 'Bob');

结果是 Bob。但如果想只改文本内容（保留属性），就得手动拼出完整新节点，没法只更新 text() 部分。

• 如果 xpath_expr 不匹配任何节点，原 XML 字符串原样返回（不会报错）
• new_xml 是纯字符串，MySQL 不校验其是否合法 XML；插入恶意字符串（如未闭合标签）会导致后续 ExtractValue 解析失败
• 不支持在 XPath 中使用变量或动态路径，也无法实现“追加子节点”或“插入同级节点”
• 性能较差：每次调用都要重新解析整段 XML，不适合高频更新字段

这两个函数在 MySQL 8.0+ 仍可用，但官方已标记为“deprecated”

从 MySQL 8.0.26 开始，文档明确标注 ExtractValue 和 UpdateXML 为“deprecated”，未来版本可能移除。它们底层依赖 libxml2，而该库在 MySQL 中长期存在内存管理缺陷（如某些畸形 XML 触发崩溃），实际线上环境出现过 segfault。

• 替代方案优先考虑 JSON：把结构化数据存为 JSON 类型，用 JSON_EXTRACT、JSON_SET、JSON_REPLACE 操作，性能更好、语法更直观、无 XML 解析风险
• 若必须用 XML，建议只在导入/导出阶段做转换，业务逻辑中避免存储和查询 XML 字段
• 已有表含 XML 字段且重度依赖这两个函数？升级前务必在测试库跑 full-scan + XPath 边界用例（如空值、嵌套超深、含 CDATA）

真实场景中容易被忽略的兼容性陷阱

MySQL 5.7 默认开启 sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，但 ExtractValue 对非法 XML 的容忍度反而比 8.0 更高 —— 有些在 5.7 返回空字符串的 case，在 8.0 直接返回 NULL，导致 WHERE ExtractValue(...) = 'x' 查询意外失效。

• 跨版本迁移时，检查所有用到这两个函数的视图、存储过程、触发器，补上 IS NOT NULL 或 IFNULL 判断
• 字符集影响结果：如果 XML 字符串是 latin1 而字段是 utf8mb4，ExtractValue 可能截断中文（因按字节解析 XPath）
• 别在 WHERE 条件里对大字段（如 TEXT）反复调用 ExtractValue —— 它无法使用索引，全表扫描不可避免