分库分表通过数据物理隔离分散并发写入，使锁作用域限于单库单表，避免跨分片锁冲突；需配合合理分片键（如user_id、哈希order_no）、精准索引、短事务及分片计数器等策略才能真正缓解锁竞争。
分库分表本身不直接“减少锁”，而是通过数据物理隔离，让原本集中在单个表/库上的并发更新请求分散到多个独立的存储单元，从而天然降低单点锁竞争强度。关键在于：锁只在本库本表内生效，跨分片不会相互阻塞。
为什么分库分表能缓解锁竞争
MySQL 的行锁、间隙锁、表锁都作用于本地存储引擎实例。当订单数据按 user_id 水平拆分到 16 个库、每个库 8 张表时，两个用户同时下单，大概率落在不同库或不同表中——它们的 INSERT 或 UPDATE 不会触发同一把 InnoDB 行锁，更不会因间隙锁范围重叠而互相等待。
常见错误现象：SHOW ENGINE INNODB STATUS 显示大量事务卡在 Waiting for a row lock，且持有锁的事务集中在少数几张大表上；information_schema.INNODB_TRX 中看到长事务持续占用锁资源。
- 垂直分表（如把
user_profile大字段拆出）可减小单行体积，提升缓冲池命中率，间接缩短锁持有时间 - 水平分片后，单表数据量下降，B+树层级变浅，索引扫描更快，锁住的索引范围更小、时间更短
- 避免所有写请求打向同一个物理节点，也就规避了该节点 CPU、IO、内存争用加剧锁排队的现象
哪些分片键能真正降低锁冲突
分片键选得不好，反而会把热点集中到个别分片，锁问题照旧。核心原则是：让高并发写入尽可能打散。
适用场景：
-
user_id或tenant_id：适合多租户、C端用户行为类业务，天然分散 -
order_no（哈希后取模）：比自增id更均匀，避免新订单总写入末尾分片 -
created_at（按月/天分表）：适合日志、流水类，但需注意月末/日初写入突增
要避开的坑：
- 用
status字段分片：所有待支付订单挤在同一个分片，锁竞争反而更剧烈 - 用连续自增
id分片：新数据总落到固定几个分片，冷热不均 - 不分片键直接用
SELECT ... FOR UPDATE全表扫描：即使分了表，也会锁住整个物理表
分库分表后仍需配合的锁优化动作
分片只是基础，不改写法、不调事务，锁问题只是转移而非消失。
- 强制要求所有分片写操作走
WHERE精准条件 + 覆盖索引，禁止无索引UPDATE触发全表扫描和间隙锁升级 - 缩短事务生命周期：分片后仍用长事务包裹跨分片逻辑？那锁会横跨多个库，风险更大
- 对高频更新的聚合字段（如用户余额），改用分片计数器（
balance_shard_0,balance_shard_1…），最后再汇总，避免单行成为锁瓶颈 - 读写分离必须搭配「写后路由」：刚在分片 A 写完订单，立刻查该订单必须走同分片 A 的主库，否则从库延迟导致重试或脏读，间接拉长锁等待链
最容易被忽略的一点：分库分表后，ALTER TABLE 变得极其危险——你不能再对所有分片同时加 MDL 锁。一个未加协调的 DDL，可能让某个分片长时间不可写，而其他分片照常服务，这种不对称性会让监控和故障定位变得异常困难。
