分库分表后UPDATE无法天然保证跨分片一致性，根本原因是架构限制而非配置问题；SELECT FOR UPDATE形同虚设因其被中间件路由至多库执行却无全局锁协调；UPDATE JOIN在跨分片场景下失效，需拆解为单表操作或采用TCC、PolarDB-X等强一致方案。
分库分表后，UPDATE 操作无法天然保证跨分片一致性，这不是配置问题，而是架构限制——你得主动收敛、拆解或兜底，没有“开箱即用”的强一致更新。
SELECT FOR UPDATE 在分库分表中为何形同虚设
ShardingSphere、MyCat 等中间件会把 SELECT FOR UPDATE 路由到多个物理库执行，但各库之间互不感知锁状态。结果就是：事务 A 锁住分片 1 的某条记录，事务 B 同时锁住分片 2 的另一条记录，两者都能成功，却可能共同破坏业务逻辑（比如并发扣减同一用户在不同分片的余额）。
- 它不会报错，也不会阻塞，行为静默但危险
- 根本原因在于：分布式锁不在 SQL 层，也不在中间件层，而需要业务自己控制
- 唯一可靠方式是让相关数据落在同一分片——例如用
user_id作分片键，把账户表、订单表、流水表都按此路由
UPDATE 多表关联更新在分布式环境下直接失效
MySQL 原生支持的 UPDATE ... JOIN 语句，在分库分表中间件里基本不可用。ShardingSphere 会尝试解析并路由，但一旦涉及跨分片 JOIN，就会抛出 UnsupportedOperationException 或静默降级为多次单表操作，导致原子性丢失。
- 不是语法写错，是中间件能力边界：它无法协调跨库的 MVCC 快照和锁生命周期
- 替代做法是拆成两步：先查主表 ID，再用 IN 列表批量更新从表——但必须确保这些 ID 全部落在同一个分片，否则仍不安全
- 若必须跨分片关联更新，只能退回到应用层双写 + 补偿机制，比如用本地消息表记录待更新项，再由定时任务驱动最终一致
如何让一次 UPDATE 看起来“强一致”
真正零妥协的强一致更新，目前只有两类路径可选：要么用 PolarDB-X 这类原生分布式数据库接管事务协调，要么用 TCC 手动编排资源预留与确认。其他方案本质都是最终一致。
-
PolarDB-X靠全局TSO时间戳实现线性一致性，UPDATE语句无需改写，但需切换 JDBC 驱动和建表语法（如指定BROADCAST或SHARDING策略） -
TCC模式下，你要把一次UPDATE拆成try_update（冻结）、confirm_update（生效）、cancel_update（释放）三个接口，侵入性强但可控 -
Seata AT虽然自动解析 SQL 生成undo_log，但它只保证单次 SQL 的回滚能力；若一个业务包含两个跨库UPDATE，且第二个失败，第一个已提交，AT 无法回滚——它不是分布式原子更新，只是单库事务的自动补偿
最常被忽略的一点：你以为加了 XA 就万事大吉，但 MySQL XA 在主从架构下极易因 Binlog 写入延迟导致从库回放失败，进而引发主从数据分裂——这比最终一致更难排查。
