MySQL 8.0 存储过程无法解析 XML 结构，XML_DECODE() 仅解码5种实体字符，不支持 XPath、节点提取或 CDATA/命名空间处理，实际解析应交由应用层完成。
MySQL 8.0 的存储过程中不能直接解析 XML 文档结构（如 XPath 查询、节点遍历），XML_DECODE() 仅能解码实体字符，不是 XML 解析器。
XML_DECODE() 只做字符解码，不解析 XML 结构
很多人误以为 XML_DECODE() 能“读取”或“提取” XML 内容，实际它只处理五种预定义实体：<、>、"、'、&。输入非标准实体（如 或自定义 &myent;）会原样返回，不报错也不转换。
- 适用场景：从
TEXT或MEDIUMTEXT字段读出已转义的 XML 片段，需还原为可读文本再交由应用层解析 - 不适用场景：提取
<title>Hello</title>中的Hello；无法替代 DOM/SAX 解析 - 性能影响：纯字符串替换，无正则回溯，O(n) 时间，对 MB 级 XML 也很快
在存储过程里安全调用 XML_DECODE() 的写法
必须显式处理 NULL 和空字符串，否则 XML_DECODE(NULL) 返回 NULL，可能引发后续 CONCAT() 或条件判断异常。
- 推荐封装成带空值防护的局部逻辑：
DECLARE v_xml TEXT DEFAULT ''; SELECT description INTO v_xml FROM products WHERE id = p_id; SET v_xml = IFNULL(v_xml, ''); SET v_xml = XML_DECODE(v_xml);
- 避免在 WHERE 子句中直接使用：
WHERE XML_DECODE(col) LIKE '%abc%'—— 无法走索引，且每次调用都触发解码 - 若需模糊匹配原始内容，应在应用层解码后搜索，或提前在插入时存两份字段：
description_encoded+description_plain
真正需要 XML 解析时的可行路径
MySQL 原生不支持 XPath（ExtractValue() 和 UpdateXML() 在 8.0.33+ 已被标记为 deprecated，8.4 将移除），没有替代函数。硬要在存储过程里“解析”，只剩三条路：
- 用字符串函数硬拆：比如
SUBSTRING_INDEX(SUBSTRING_INDEX(xml_col, '<name>', -1), '</name>', 1)—— 仅适用于格式绝对固定、无嵌套、无属性的玩具数据 - 把 XML 转成 JSON 再用
JSON_EXTRACT()：前提是 XML 结构规整且可预测，需手写转换逻辑（例如用REPLACE()把<item>换成{"item":），极易出错 - 放弃存储过程内解析：将含 XML 的字段查出后，在应用层（Python/Java/Node.js）用成熟 XML 库处理 —— 这是绝大多数生产系统的实际选择
最常被忽略的一点：哪怕你用 XML_DECODE() 解出了干净字符串，只要原始 XML 含有 CDATA、命名空间、PI（处理指令）或 DTD 声明，这些内容它完全不碰——它们根本不在五字符解码范围内。真要处理这类 XML，别在数据库里硬扛。
