MySQL无法可靠解析复杂XML，ExtractValue和UpdateXML仅为临时补丁且已在8.0.26+弃用；其仅支持XPath 1.0极小子集，对命名空间、CDATA、混合文本、未闭合标签及非法字符（如未转义&）完全无能为力。
MySQL 无法可靠解析复杂 XML，ExtractValue 和 UpdateXML 不是解决方案，而是临时补丁，且已在 8.0.26+ 标记为 deprecated。
ExtractValue 在真实 XML 上大概率返回 NULL
它只支持 XPath 1.0 极小子集，对命名空间、CDATA、混合文本、未闭合标签、非法字符（如未转义的 & 或 ）完全无感——不报错，直接静默返回 <code>NULL。
- 常见错误现象：
ExtractValue(xml_col, '//item/title')在测试数据里能取到值，上线后面对带xmlns="http://example.com"的 RSS 或 SOAP 响应，始终返回NULL - 它不识别
rss:item这类带前缀的路径，//rss:item/rss:title必败；默认命名空间同理 - 匹配多个节点时，只返回第一个的文本内容，其余被丢弃，且无法控制顺序（
//item[1]可用，//item[position()=1]报错） - 在
WHERE子句中使用会导致全表扫描——ExtractValue无法走索引，性能雪崩
UpdateXML 修改的是整节点，不是“更新文本”
UpdateXML 的行为容易误解：它不是修改节点内容，而是用新 XML 片段**替换整个匹配节点**。想只改 <title>Old</title> 里的文本，你必须手动拼出完整的新节点 <title>New</title>，否则会丢失属性或子结构。
- 示例：
UpdateXML('<user id="1">Alice</user>', '/user', '<user id="2">Bob</user>')才能保留id属性；若传入'Bob'，结果变成<user id="1">Bob</user>——id被覆盖为原始值，但语义已错乱 - 若 XPath 不匹配任何节点，函数原样返回输入 XML，不会警告，极易掩盖逻辑错误
- 它不能增删节点、不能处理注释（
<!-- comment -->）、不能处理处理指令（<?xml version="1.0"?>），遇到就截断或失效
MySQL 8.0+ 应该用 REGEXP_SUBSTR，5.7 只能靠 SUBSTRING_INDEX
当 XML 结构固定、无嵌套干扰、无命名空间时，字符串切片比硬扛 XPath 更可控、更可测。
- MySQL 8.0+ 推荐：
REGEXP_SUBSTR(xml_data, '<status>([^', 1, 1, '', 1)</status>——[^ 比 <code>.*?安全，避免跨标签捕获 - MySQL 5.7 兼容写法：
SUBSTRING_INDEX(SUBSTRING_INDEX(xml_data, '<status>', -1), '</status>', 1)—— 两层SUBSTRING_INDEX模拟“中间提取” - 注意：这两种方式都假设标签成对、无换行缩进干扰；若 XML 含有 CDATA 或属性值含
，仍会失败
真正复杂的 XML 必须交给应用层解析
只要 XML 含以下任一特征，就别在 SQL 层处理：xmlns 声明、任意嵌套、注释、处理指令、属性值含特殊字符、文档超 1MB。
- MySQL 每次调用
ExtractValue都触发完整 XML 重解析，无缓存；字段超 5MB 可能 OOM 或锁表 - 主从复制中，因函数不可重复执行（non-deterministic），可能引发延迟甚至中断
- 正确做法：把
xml_data字段读出，在 Python 用xml.etree.ElementTree、Java 用DocumentBuilder、Go 用encoding/xml解析——标准库健壮、可调试、支持命名空间和错误定位 - 如果必须数据库内清洗，优先用存储过程剥离
xmlns、移除注释、规范化换行，再喂给ExtractValue；但这类逻辑本身已超出 SQL 表达能力
别低估命名空间和非法字符的破坏力——它们不是边缘情况，而是生产 XML 的常态。ExtractValue 的“能跑通”往往只是还没撞上真实数据结构。
