分布式SQL中单条INSERT不保证跨节点原子性，因其执行路径为解析→路由→并行下发→各节点独立提交；必须依赖Raft或2PC协议才能实现强一致性，如CockroachDB默认支持，TiDB需匹配事务模式配置。
分布式 SQL 中单条 INSERT 不保证跨节点原子性
多数分布式 SQL 数据库（如 TiDB、CockroachDB、YugabyteDB）对单条 INSERT 的处理是：解析 → 按分布键路由到多个分片 → 并行下发 → 各节点独立提交。这意味着，哪怕语句写法看起来是“一条”，实际执行并不具备跨节点的原子性。
常见错误现象包括：插入后查不到部分数据、唯一键在不同分片重复插入成功、事务提交后部分节点回滚失败导致状态不一致。
- MySQL Group Replication 默认只保证“多数派写入”，不等所有节点落盘就返回成功
- PostgreSQL Citus 的
INSERT INTO distributed_table会按哈希路由，但各目标节点COMMIT时间点不同步，无全局协调锁 - AlaSQL 等嵌入式引擎根本不支持跨实例事务，所谓“分布式 INSERT”只是应用层拼 SQL
必须启用 Raft 或 2PC 才能约束跨节点 INSERT 原子性
真正能让 INSERT 跨节点强一致的，只有两类底层协议：基于共识日志的单次提交（如 Raft log append + apply），或两阶段提交（2PC）。
关键配置差异直接影响行为：
- CockroachDB 默认开启
STRICT SERIALIZABLE隔离级 + Raft 日志同步，INSERT天然具备跨节点原子性 - TiDB 需确认
tikv_gc_life_time和tidb_txn_mode='optimistic'匹配业务场景；若用悲观事务模式，需注意锁等待超时风险 - Oracle XA 或 PostgreSQL 的
PREPARE TRANSACTION可启用 2PC，但性能开销大，且 coordinator 故障会导致事务卡在PREPARE状态
别指望 ON DUPLICATE KEY UPDATE 解决跨分片一致性
INSERT ... ON DUPLICATE KEY UPDATE 在单分片内有效，但跨分片时完全失效——因为唯一键冲突检测只发生在本地节点，不同分片之间不共享索引状态。
典型陷阱：
- 用户 A 和 B 的记录被路由到不同分片，同时插入相同
username，两个分片都判定“无冲突”并各自插入，最终出现重复 - 该语法不参与任何分布式事务协议，即使包裹在
BEGIN/COMMIT中，也无法触发跨节点协调 - 在 READ COMMITTED 隔离级下，并发
INSERT可能因读取不同快照，导致唯一约束冲突延迟报出，掩盖真实不一致
应用层必须承担最终一致性责任
即便数据库声称支持分布式事务，网络分区或 coordinator 崩溃仍会导致事务卡在中间状态。此时数据库无法自动恢复，必须由应用兜底。
实操建议：
- 为每次跨节点
INSERT生成唯一request_id，先写入本地状态表（字段含status:pending/committed/rolled_back） - 插入前查该
request_id是否已存在，避免重复执行 - 触发器不能用于跨库操作——它运行于本地事务上下文，无法注册为 XA resource；改用本地消息表 + 独立补偿服务消费
最易被忽略的一点：跨节点 INSERT 的“成功”响应，只代表协调器收到了全部 ACK，不代表所有副本已完成 apply；查数据前必须考虑复制延迟或显式指定读取主库。
