MySQL不支持跨库/跨实例分布式事务，XA仅限单机多引擎；SELECT...FOR UPDATE非分布式锁；分布式锁应选Redis或Etcd；高并发场景宜用最终一致性方案。
MySQL 本身不支持跨库/跨实例的分布式事务
MySQL 的 XA START 和 XA COMMIT 确实提供了 XA 协议接口，但仅限于单机内多个存储引擎（如 InnoDB + NDB）协作，且实际生产中极少启用。跨 MySQL 实例（比如分库分表场景）的「真正分布式事务」必须依赖外部协调者，比如 Seata、ShardingSphere-Transaction 或自研 TCC 框架。直接在应用层用 START TRANSACTION + 多个 INSERT INTO db1.t1 和 INSERT INTO db2.t2 是无效的——每个连接只作用于一个实例，根本无法保证原子性。
MySQL 的 SELECT ... FOR UPDATE 不是分布式锁
它只在当前数据库连接的事务内加行级锁，且锁范围受限于隔离级别和索引条件。一旦连接断开或事务提交/回滚，锁立刻释放。跨服务、跨 JVM 进程时，这个锁完全不可见、不可感知。常见误用是：服务 A 执行 SELECT id FROM stock WHERE sku='A' FOR UPDATE 后去调用服务 B 的扣减接口，服务 B 又自己连 MySQL 做一次 UPDATE —— 这中间没有全局锁保护，库存超卖风险极高。
真正可用的分布式锁方案要绕开 MySQL 单点依赖
用 MySQL 实现分布式锁（比如 INSERT INTO lock_table (key, expire) VALUES ('order_123', NOW() + INTERVAL 30 SECOND) ON DUPLICATE KEY UPDATE expire = VALUES(expire)）看似可行，但存在几个硬伤：
- 锁续期困难：MySQL 没有原生 TTL 和自动清理机制，靠定时任务清理易漏、易冲突
- 主从延迟导致锁判断失效：从库读到过期锁状态，误判为可获取
- 网络分区时脑裂：两个节点都以为自己持锁，同时写入
生产环境更推荐 Redis + Redlock（注意：Redis 官方已不推荐 Redlock，但单 Redis 实例 + SET key value EX 30 NX 配合合理超时，在多数场景下足够可靠），或 Etcd/ZooKeeper 这类强一致协调服务。
什么时候该放弃“分布式”幻想，改用最终一致性
高并发下单扣库存、支付回调更新订单状态这类场景，硬上分布式事务或分布式锁，往往带来巨大性能损耗和运维复杂度。更务实的做法是：
- 本地事务先落库（比如写一条「待扣减」流水），再发 MQ 异步执行真实扣减
- 用定时任务或消费 MQ 补偿失败操作，配合幂等键（如
order_id + action_type）防止重复处理 - 前端展示「处理中」状态，而非强等锁或两阶段提交结果
MySQL 在这里只是持久化载体，不是协调中心。把一致性保障逻辑从数据库上移，才能真正应对分布式系统的不确定性。
-- 示例：错误的「伪分布式锁」写法（不要这么用）
INSERT INTO distributed_lock (lock_key, owner, expire_time)
VALUES ('stock_sku_A', 'service_a', DATE_ADD(NOW(), INTERVAL 30 SECOND))
ON DUPLICATE KEY UPDATE
owner = VALUES(owner),
expire_time = VALUES(expire_time);
-- 问题：没检查原锁是否已过期，也没做原子性校验真正难的不是写对一行 SQL，而是想清楚「这把锁到底要拦住谁」「超时后谁来兜底」「失败了用户看到什么」。MySQL 在分布式系统里，永远只是配角。
