ExtractValue() 在复杂 XML 场景下大概率失败，因其不支持命名空间、无法逐行提取重复节点、遇非法字符或空输入静默返回 NULL、每次调用重建 DOM 导致性能指数下降。
ExtractValue() 能解析，但对“复杂 XML”基本不可靠——它不支持命名空间、不能处理重复节点的逐行提取、遇到非法字符或空输入就静默返回 NULL，且每次调用都重建 DOM，性能随 XML 长度指数下降。
为什么 ExtractValue() 在复杂 XML 场景下大概率失败
复杂 XML 通常含以下特征，而 ExtractValue() 全部不支持：
- 带命名空间前缀（如
<ns:person xmlns:ns="http://example.com">），ExtractValue()完全忽略命名空间，路径写成/ns:person/name直接返回NULL - 同级多节点需逐行输出（如多个
<item>），ExtractValue(xml, '//item')会把所有内容拼成一个空格分隔字符串，无法拆成多行结果集 - 属性与文本混用（如
<row id="101">data</row>），用/row/@id和/row分开取值时，若某条记录缺失@id，整个表达式返回NULL，无提示 - XML 中含未转义字符（如原始文本里的
&、），<code>ExtractValue()不校验合法性，直接解析失败并静默返回NULL
MySQL 8.0.33+ 必须加 XMLVALIDATE() 校验输入
旧版 MySQL（）没有校验手段，只能靠人工肉眼排查；8.0.33 起引入 <code>XMLVALIDATE()，必须在 ExtractValue() 前使用：
IF xml_str IS NOT NULL AND LENGTH(xml_str) > 0 AND XMLVALIDATE(xml_str) THEN SET name = ExtractValue(xml_str, '/root/person/name'); ELSE SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid XML'; END IF;
注意：XMLVALIDATE() 仅验证 Well-formed，不校验 DTD 或 XSD；若 XML 含 BOM 或 UTF-8 以外编码（如 GBK），仍会失败。
替代方案：结构固定时，用字符串函数硬解更稳
当 XML 格式稳定、标签简单（如 <name>Alice</name>）、且无需 XPath 灵活性时，SUBSTRING_INDEX() + REPLACE() 比 ExtractValue() 快 3–5 倍，且不会因路径错或命名空间崩：
- 提取
<name>Alice</name>：SUBSTRING_INDEX(SUBSTRING_INDEX(ucs_info, '<name>', -1), '</name>', 1) - 提取属性
<item id="123">：SUBSTRING_INDEX(SUBSTRING_INDEX(ucs_info, 'id="', -1), '"', 1) - 需防空值干扰，建议套
TRIM()和IFNULL(..., '')
缺点是无法处理嵌套层级深或标签名动态变化的场景，但胜在确定性高、无隐式失败。
要逐行提取重复节点？别用 WHILE 模拟循环
常见错误写法是用 count(//item) + WHILE 循环调用 ExtractValue()，问题极多：
-
count(//item)本身也受 XML 合法性影响，非法 XML 下返回NULL，导致WHILE条件恒假 - 循环内每次
ExtractValue()都重建 DOM，100 个<item>就执行 100 次解析，CPU 占用飙升 - MySQL 存储过程不支持动态 SQL，无法拼接
//item[1]、//item[2]这类路径
真正可行的做法只有两个：
- 把 XML 拆成单条记录存入临时表（如用应用层预处理成 CSV/JSON 再导入）
- 改用外部工具（Python 的
lxml或 Java 的DOMParser）解析后批量 INSERT，MySQL 只负责存结果
硬要在存储过程中做，唯一勉强能用的是：先用正则式（REGEXP_SUBSTR，MySQL 8.0.4+）切出每段 <item>...</item>，再对每段调用 ExtractValue() —— 但这已超出存储过程设计初衷，维护成本极高。
