extractvalue 总返回 null 主因是 xpath 错误或 xml 结构不符，且函数对大小写、命名空间、层级敏感却不报错；updatexml 不修改原数据，需配合 update 使用；二者已弃用，存在 xxe 安全风险，推荐改用 json 函数。
EXTRACTVALUE 为什么总返回 NULL？
不是字段没数据，而是 XPath 表达式写错了，或者 XML 结构和预期不一致。MySQL 的 EXTRACTVALUE 对大小写、命名空间、节点层级极其敏感，且不报错——只默默返回 NULL。
-
EXTRACTVALUE第二个参数必须是合法 XPath 1.0 表达式，不支持//简写（如//name在某些版本会失效），推荐用绝对路径或.//name - XML 字符串里如果有换行或多余空格，不影响解析；但若含未转义的
&、、<code>>，会导致整个 XML 解析失败，EXTRACTVALUE返回NULL - 如果字段值是
NULL或非 XML 格式字符串（比如纯 JSON），结果也一定是NULL，不会报错 - 示例：假设
xml_data字段存有<root><user id="101"><name>Alice</name></user></root>，取 name 值应写：EXTRACTVALUE(xml_data, '/root/user/name')，而不是'//name'或'/user/name'
UPDATEXML 修改 XML 内容时值没变？
UPDATEXML 不是“更新字段”，而是“返回修改后的新 XML 字符串”——它本身不改变原数据，必须配合 UPDATE ... SET col = UPDATEXML(...) 才生效。
- 第一个参数要是完整的 XML 字符串（或字段名），第二个是 XPath，第三个是替换内容（字符串，不是表达式）
- 如果 XPath 找不到匹配节点，
UPDATEXML直接返回原 XML，**不会报错也不会警告**，看起来就像“没改成功” - 替换内容里的引号必须转义：想插入
value="test"，得写成'value=\"test\"'；否则 SQL 解析失败 - 性能上，每次调用都会完整解析并重建 XML 字符串，大数据量更新时比 JSON 函数慢得多（MySQL 5.7+ 推荐优先用
JSON_SET处理结构化数据） - 示例：把上面的
name改成Bob，要这样写：UPDATE t SET xml_data = UPDATEXML(xml_data, '/root/user/name', '<name>Bob</name>') WHERE id = 123
MySQL 5.7 和 8.0 下这两个函数还能用吗？
能用，但已被标记为“过时（deprecated）”，官方文档明确建议迁移到 JSON 函数。8.0.22 起，如果启用了 sql_mode=ERROR_FOR_DIVISION_BY_ZERO 类似严格模式，部分非法 XPath 可能触发警告而非静默失败。
- MySQL 5.7 默认启用
ONLY_FULL_GROUP_BY等模式，但不影响EXTRACTVALUE/UPDATEXML本身；真正影响的是你是否在 SELECT 中混用非 GROUP BY 字段 - 8.0.13+ 开始，XML 函数对 UTF-8 编码更严格：原始 XML 若声明了
encoding="ISO-8859-1"但实际是 UTF-8 字节，解析可能出错 - 替代方案优先级：纯标签提取 →
REGEXP_SUBSTR（8.0+）；结构化更新 →JSON_EXTRACT/JSON_SET（哪怕把 XML 当字符串预处理成 JSON） - 注意：
EXTRACTVALUE最多只返回前 512 个字符，超长会被截断——这不会报错，但容易漏数据
用它们处理用户提交的 XML 安全吗？
不安全。这两个函数不做过滤、不防 XXE、不校验 DTD，直接传入用户输入等于敞开 XML 外部实体攻击（XXE）大门。
- 只要 XML 字符串里含
]>这类声明，EXTRACTVALUE在某些配置下可能触发读取本地文件 - MySQL 默认禁用外部实体加载，但若服务器启用了
--local-infile或自定义 libxml2 编译选项，风险上升 - 真实业务中，应该在应用层做 XML 白名单清洗（比如只保留
<user></user><name></name>等几个标签），或直接拒绝 XML 输入，改用 JSON + Schema 校验 - 测试时别用
SELECT EXTRACTVALUE('<?xml version="1.0"?> ]><a>&b;</a>', '//a')—— 这条在某些环境真能读到系统信息
