必须显式授予xa_recover_admin权限，因该权限不包含在grant all中；普通账号执行xa recover报error 1401本质是权限缺失，mysql 8.0.29+起process权限已不足，须单独执行grant xa_recover_admin on . to 'user'@'host';并flush privileges。
XA RECOVER 权限必须显式授予，不能靠 GRANT ALL
执行 XA RECOVER 查看悬挂事务时，普通账号常报错 ERROR 1401 (XAE03): XAER_RMERR: fatal error occurred，根本原因不是配置错，而是权限缺失。MySQL 8.0.29+ 引入了专用权限 XA_RECOVER_ADMIN，它不包含在 GRANT ALL PRIVILEGES 里，也不属于 SUPER 或 PROCESS 的子集。
常见错误做法是只给 SELECT 或 PROCESS（旧版兼容用），但 8.0.29+ 中 PROCESS 已不足以支撑 XA RECOVER —— 必须单独授权：
GRANT XA_RECOVER_ADMIN ON *.* TO 'app_user'@'10.20.%';- 授权后需执行
FLUSH PRIVILEGES;生效 - 验证方式：用该账号登录后直接执行
XA RECOVER;，不报错即成功
XA START/COMMIT/ROLLBACK 不需要特殊权限，但表和引擎有硬约束
XA START、XA PREPARE、XA COMMIT 这些命令本身不校验额外权限，只要用户对涉及的表有对应 DML 权限（如 INSERT、UPDATE）即可。但它们会静默失败或报错，如果底层不满足条件：
- 表必须是
InnoDB引擎 ——MyISAM执行XA START会返回XAER_NOTA，且无明确提示 - 必须使用显式事务 ID（如
XA START 'gtrid-001';），空字符串或重复 ID 会触发XAER_DUPID或XAER_OUTSIDE - 同一连接中不能混用普通事务与 XA 事务：
BEGIN后再XA START会报XAER_RMFAIL
max_prepared_transactions 影响的是准备态持久化，不是权限问题
很多人把 XA PREPARE 失败归咎于权限，实际更可能是 max_prepared_transactions 为默认值 0。这个参数控制 MySQL 能同时缓存多少个已 PREPARE 但未 COMMIT/ROLLBACK 的事务状态。设为 0 意味着完全禁用准备态持久化，此时 XA PREPARE 直接报 ERROR 1399 (XAE09): XAER_RMFAIL。
修复方式不是加权限，而是改配置：
- 在
my.cnf的[mysqld]段添加：max_prepared_transactions=128 - 值建议 ≥ 预期峰值并发 XA 事务数 × 1.5，最低不低于 32
- 修改后必须重启 MySQL，
SET GLOBAL动态设置无效
权限 + 配置 + 引擎三者缺一不可，最容易漏掉的是 XA_RECOVER_ADMIN
线上出问题时，往往先查 SHOW ENGINES; 确认 InnoDB 的 XA 列为 YES，再确认 max_prepared_transactions > 0，最后才想到权限。但真实故障里，XA RECOVER 报错占悬挂事务排查类问题的 70% 以上，而其中绝大多数就是没授 XA_RECOVER_ADMIN。
别依赖“我给了所有权限”，XA 相关操作的权限粒度很细，且版本差异大 —— 8.0.29+ 必须显式、单独、精确授予。
