CockroachDB和TiDB均不支持XML作为事务数据载体，所谓“XML上传的分布式事务”并不存在；事务仅作用于SQL操作层面，XML内容被当作普通字符串处理，数据库不解析、不校验、不按节点回滚。
不处理。CockroachDB 和 TiDB 都不支持 XML 作为事务数据载体，更不存在“XML 上传的分布式事务”这一概念。
为什么没有 XML 上传的分布式事务 这回事
分布式 SQL 数据库（如 CockroachDB、TiDB）的事务机制作用于 SQL 语句层面，不是文件或文档格式层面。所谓“上传 XML”，本质是应用层行为：要么解析后转成 INSERT/UPDATE，要么存为 TEXT 或 BYTEA 字段——事务只保障这些 SQL 操作的原子性，和 XML 语法、结构、验证完全无关。
-
XML不是 CockroachDB 或 TiDB 的内置数据类型；TiDB 支持XML函数（如EXTRACTVALUE），但仅用于字符串解析，不参与事务协调 - CockroachDB 明确不支持任何 XML 函数或类型，尝试插入带 XML 内容的字符串会当作普通
STRING处理 - 所谓“上传”，若指 HTTP 接口接收 XML 并写入数据库，那事务边界在应用代码里（比如用
BEGIN/COMMIT包裹多条 SQL），数据库只执行你发过去的语句
INSERT INTO ... VALUES ('1 算不算 XML 事务
算，但只是“把一串字符存进去”的事务，不是“按 XML 结构提交事务”。关键点在于：
- XML 内容被当作文本字面量，数据库不做 schema 校验、DTD/XSD 解析或元素级回滚
- 如果 XML 很大（比如 10MB），可能触发 CockroachDB 的
max_row_size限制（默认 128MB，可调）或 TiDB 的max_allowed_packet（默认 64MB） - 并发写同一行 XML 字段时，会正常触发行锁（TiDB 的乐观锁 / CockroachDB 的悲观锁模式下），但锁的是整行，不是某个 XML 节点
真要基于 XML 做多步一致性操作，该怎么做
必须由应用层拆解 XML 并映射为关系操作，再交由数据库事务保障。例如：
INSERT INTO orders (id, status) VALUES (1, 'pending'); INSERT INTO order_items (order_id, sku, qty) VALUES (1, 'A123', 2), (1, 'B456', 1); UPDATE customers SET balance = balance - 199.99 WHERE id = 123;
上面这三句应包裹在同一个事务中（如用 BEGIN / COMMIT），而 XML 只是应用读取、解析、生成这些语句的中间格式。常见错误包括：
- 误以为调用一次
INSERT就能“提交整个 XML 文档事务”，结果部分节点入库失败却没回滚其余 - 在 TiDB 中用
LOAD DATA导入 XML 文件（不支持），或误配tidb_enable_xml（该变量仅控制是否允许 XML 函数语法，不影响存储或事务） - CockroachDB 应用未设置
serializable隔离级别（默认），导致 XML 解析逻辑依赖的读取结果被其他事务覆盖
真正容易被忽略的是：XML 解析本身不在数据库事务范围内。哪怕数据库事务 100% 成功，XML 解析出错、字段映射错位、空值未处理，都会导致业务逻辑损坏——这部分必须在应用侧做完整校验和重试，不能指望数据库兜底。
