<p>真实原因是权限缺失，而非配置错误：执行XA RECOVER报ERROR 1401 (XAE03)时，99%因用户缺少XA_RECOVER_ADMIN权限；该权限需显式授予且不包含于GRANT ALL中，必须执行GRANT XA_RECOVER_ADMIN ON . TO 'user'@'host'。</p>
XA RECOVER 报错 ERROR 1401 (XAE03) 的真实原因
这不是配置错误，而是权限缺失。执行 XA RECOVER 时看到 ERROR 1401 (XAE03): XAER_RMERR: fatal error occurred，99% 是因为账号没被授予 XA_RECOVER_ADMIN 权限 —— MySQL 不会提示“权限不足”，而是伪装成底层故障，误导你去查日志或重连。
必须用 GRANT XA_RECOVER_ADMIN 显式授权
这个权限不能通过 GRANT ALL PRIVILEGES 自动包含，也不能靠 PROCESS 权限替代（旧版兼容方案已过时）。MySQL 8.0.29+ 强制要求专用权限：
GRANT XA_RECOVER_ADMIN ON *.* TO 'your_user'@'host';- 必须指定
ON *.*，不支持库级或表级粒度 - 授权后需执行
FLUSH PRIVILEGES;（仅当使用mysqld --skip-grant-tables启动时才需要；正常情况不用） - 若用户已存在且连接活跃，新权限在下次新建连接时生效（当前连接不会自动更新权限缓存）
验证权限是否真正生效
别只信 SHOW GRANTS 输出——它可能显示权限但实际未加载。最可靠的方式是直接测试：
- 用该用户登录：
mysql -u your_user -p - 执行：
XA RECOVER; - 成功返回空结果集（说明无悬挂事务）或列出
xid列表，即表示权限到位 - 如果仍报错，检查是否用了
root@localhost而不是root@'%'—— host 匹配必须精确
容易被忽略的部署细节
XA 分布式事务的权限问题常卡在运维交接环节：应用连接池用的账号、监控脚本用的账号、DBA 手动排查用的账号，三者权限经常不一致。尤其当 Atomikos 或 Seata 等中间件后台定期调用 XA RECOVER 时，它用的是连接池配置的账号，而不是你本地登录的账号。务必确认中间件配置文件里写的用户名，在数据库中已被授予 XA_RECOVER_ADMIN。
