执行xa recover报错error 1401 (xae03)是因用户缺少xa_recover_admin权限，需执行grant xa_recover_admin on . to 'user'@'%';并flush privileges;生效。
执行 XA RECOVER 报错 ERROR 1401 (XAE03) 怎么办
这是最常遇到的权限问题：用户没被授予 XA_RECOVER_ADMIN 权限，导致无法调用 XA RECOVER 查看悬挂事务。MySQL 8.0.30+ 强制要求该权限，旧版本（如 5.7）则依赖 SUPER，但不推荐沿用。
直接授予权限即可解决：
GRANT XA_RECOVER_ADMIN ON *.* TO 'your_user'@'%';
注意：XA_RECOVER_ADMIN 是细粒度权限，无需给 SUPER 或 SYSTEM_VARIABLES_ADMIN 等高危权限。授完需执行 FLUSH PRIVILEGES; 生效。
XA START / XA PREPARE 等命令为什么被拒绝
除了 XA_RECOVER_ADMIN，其他 XA 操作本身不额外校验权限——只要用户有对应数据库/表的 SELECT、INSERT、UPDATE、DELETE 权限，就能在 XA 事务中执行这些语句。
但如果命令直接报错（如 ERROR 1227 (42000): Access denied），常见原因有：
- 用户连接时启用了
--skip-grant-tables，但权限系统未加载完整 - MySQL 配置了
require_row_format = ON或只读模式，间接阻断 XA 流程 - 使用了代理（如 ProxySQL、MaxScale），它拦截或重写 XA 命令，而代理自身未配置透传支持
验证方式：用 root 用户本地连接执行相同 XA START，若成功，则问题出在目标用户权限链或中间件上。
为什么设置了 max_prepared_transactions 还是失败
这个参数不是权限，而是资源上限控制。如果并发 XA 事务数超过 max_prepared_transactions 值，XA PREPARE 会返回 ERROR 1399 (XAE04): XAER_RMFAIL。
它必须在所有参与 XA 的 MySQL 实例上统一配置，且值要 ≥ 预期最大并发 XA 分支数。例如 5 个服务节点，每个最多启动 20 个分支，则建议设为 100 或更高：
[mysqld] max_prepared_transactions = 128
重启实例生效。注意：该值不能动态修改，且设得过大可能占用额外内存（每个 prepared 事务保留 undo log 和状态结构）。
应用层用 JDBC 调 XA 时提示 “Access denied for user”
这不是 SQL 权限问题，而是 JDBC 驱动在初始化 XA 连接时，会尝试执行 XA RECOVER 自动清理残留事务。如果应用连接的用户没有 XA_RECOVER_ADMIN，驱动就抛异常中断连接。
解决方案只有两个：
- 给应用账号明确授予
XA_RECOVER_ADMIN（推荐） - 在 JDBC URL 中加参数禁用自动恢复：
&useLocalSessionState=true&allowMultiQueries=true（不治本，仅绕过）
别指望靠 SET SESSION autocommit = 0 或改隔离级别来规避——XA 的权限检查发生在协议层，与 SQL 会话设置无关。
XA 权限问题往往藏得深：它不报“missing privilege”，而报“fatal error”或“access denied”，容易误判为网络或认证故障。真正要盯住的，永远是 XA RECOVER_ADMIN 是否到位，以及 max_prepared_transactions 是否撑得住实际负载。
