ExtractValue仅支持XPath 1.0极小子集，无法处理命名空间、CDATA、混合文本、非法字符等；推荐用REGEXP_SUBSTR（8.0+）或SUBSTRING_INDEX（5.7）替代，复杂XML必须交由应用层解析。
ExtractValue 函数根本不能处理任意 XML
MySQL 的 ExtractValue 不是通用 XML 解析器，它只支持 XPath 1.0 的极小子集，且对命名空间、CDATA、属性节点嵌套、文本节点混合结构完全无能为力。一旦 XML 含有前缀（如 <rss:channel>）、默认命名空间或换行缩进后的格式化内容，ExtractValue 就大概率返回空或报错。
常见错误现象：ExtractValue(xml_col, '//item/title') 在测试简单 XML 时正常，但上线后对真实 RSS 或 SOAP 响应体返回 NULL —— 很可能因为实际数据含 xmlns 声明，而 MySQL 压根不识别。
- 只支持无命名空间的扁平路径，
//item/title可用，//rss:item/rss:title必败 - 无法提取属性值以外的文本节点混合内容（比如
<p>Hello<b>world</b></p>中的 “Hello”） - 遇到非法字符（如未转义的
&、<）会直接截断解析，不报错也不提示
替代方案：用 SUBSTRING_INDEX + REGEXP 替代简单字段提取
当 XML 结构固定、标签成对出现、无嵌套干扰时，正则+字符串切片比硬扛 ExtractValue 更稳。MySQL 8.0+ 支持 REGEXP_SUBSTR，5.7 只能靠 SUBSTRING_INDEX 配合多层嵌套。
使用场景：从日志表的 xml_data 字段里提取 <status>success</status> 这类单层标记值。
- MySQL 8.0+ 推荐写法：
REGEXP_SUBSTR(xml_data, '<status>([^<]+)</status>', 1, 1, '', 1) - 兼容 5.7 的保守写法：
SUBSTRING_INDEX(SUBSTRING_INDEX(xml_data, '<status>', -1), '</status>', 1) - 注意：正则中的
[^<]+比.*?更安全，避免跨标签误匹配
XML 超出 MySQL 处理能力时必须换地方解析
只要 XML 含命名空间、注释、处理指令（<?xml version="1.0"?>）、或任意复杂嵌套，就别在 SQL 层硬刚。MySQL 的 XML 功能本质是“应急补丁”，不是生产级工具。
性能与兼容性影响：每次调用 ExtractValue 都触发完整 XML 重解析，无缓存；字段长度超 5MB 时可能 OOM 或锁表；在主从复制中还可能因函数不可重复执行导致延迟或中断。
- 正确做法：把 XML 字段读到应用层（Python/Java/Go），用标准库解析（如 Python 的
xml.etree.ElementTree） - 如果必须数据库内处理，考虑前置清洗：用存储过程或外部脚本先剥离命名空间、规范化缩进、转义非法字符，再喂给
ExtractValue - 绝对不要在 WHERE 条件里用
ExtractValue做过滤 —— 它无法走索引，全表扫描不可避免
ExtractValue 的 XPath 写法陷阱
看似简单的路径表达式，实际踩坑密集。MySQL 对 XPath 的实现和标准差异极大，连 text() 和 . 都不等价。
参数差异示例：ExtractValue('<root><a>1</a><a>2</a></root>', '//a') 返回的是两个值拼接的字符串 "1 2"（空格分隔），不是数组，也不能用 [@attr='x'] 精确匹配某一个。
-
//a/text()在 MySQL 中无效，必须写成//a（隐式取文本） -
/root/a[1]可用，但/root/a[position()=1]报错 —— 不支持函数谓词 - 路径开头加
/是绝对路径，不加是相对路径；但 MySQL 一律按文档根处理，加不加效果相同
