MySQL服务端不提供xa_transaction_timeout或类似配置项，XA事务超时由外部协调者（如Seata、Atomikos）控制，MySQL仅通过max_prepared_transactions限制并发PREPARED事务数，需重启生效，且不自动回滚僵死事务。
MySQL XA事务本身没有超时参数可配
直接回答：MySQL服务端不提供 xa_transaction_timeout 或类似配置项。XA事务的“超时”行为不是由MySQL主动控制的，而是依赖外部协调者（如应用层、中间件或JTA容器）来判断和干预。
这意味着，如果你只在MySQL里执行 XA START → XA PREPARE，然后挂起不管，这个事务会一直停留在 PREPARED 状态，锁住行和连接，直到手动处理或MySQL重启——它不会自动回滚。
常见错误现象包括：
– XA RECOVER 持续返回未完成事务
– performance_schema.data_locks 显示大量 GRANTED 的行锁长期不释放
– 后续SQL因锁等待触发 Lock wait timeout exceeded
真正起作用的是客户端/协调者的超时逻辑
XA事务的生命周期管理责任在事务管理器（TM），比如 Seata、Atomikos、MyCAT，或你自己写的JDBC调度逻辑。它们通过以下方式实现“超时”：
- 定时轮询
XA RECOVER结果，比对事务启动时间戳与当前时间差 - 在
XA PREPARE后启动守护线程或异步任务，到期未收到COMMIT/ROLLBACK就强制发起XA ROLLBACK - 在应用层设置网络调用超时（如
rpcTimeout=5000），防止分支响应卡死
例如 Atomikos 中需配置：com.atomikos.icatch.max_timeout=60000（单位毫秒，控制事务最大存活时间）com.atomikos.icatch.default_jta_timeout=30000（JTA事务默认超时）
而 MyCAT 作为TM时，其 server.xml 中的 xaTimeout 属性才是实际生效的超时阈值。
MySQL侧唯一能间接影响XA事务“僵死”的配置是 max_prepared_transactions
这个参数不控制超时，但决定MySQL最多允许多少个并发 PREPARED 状态事务存在。如果设得太小（如默认 0 或 10），新 XA PREPARE 会直接失败并报错：ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the PREPARED state
建议按预期并发量设置：
– 生产环境至少设为 100 或更高
– 配置位置：[mysqld] 段下的 max_prepared_transactions=100
– 修改后必须重启MySQL才生效
注意：该值过大也不会导致内存暴涨，InnoDB只为每个 prepared 事务维护少量元数据，但过小会直接阻断XA流程。
如何发现和清理已超时的XA事务
没有自动超时不代表放任不管。你得主动监控和干预：
- 定期执行
XA RECOVER，解析返回的xid，结合业务日志判断是否异常滞留 - 用
SELECT * FROM performance_schema.events_transactions_current WHERE STATE = 'ACTIVE'查看长时间未结束的事务 - 对确认超时的事务，用
XA ROLLBACK 'xid_string'手动清理（注意：xid 必须完全匹配，包括格式和大小写） - 避免直接 kill 连接，否则可能留下
orphaned prepared transaction，需靠 MySQL 重启或innodb_force_recovery处理
最易被忽略的一点：XA事务的 xid 是二进制字符串，在 XA RECOVER 输出中是十六进制编码，还原时需用 UNHEX() 转换，否则 XA COMMIT 会报 XAER_NOTA 错误。
