分区表执行_SPLIT会锁全表，因InnoDB对分区操作常升级为全表MDL写锁，TiDB和PostgreSQL也存在调度阻塞或长事务锁问题；应改用灰度迁移（如双写+原子切换）而非原生DDL。

分区表执行 _SPLIT 时为什么会锁全表

mysql（尤其是 5.7/8.0 的 innodb）在对 range/list 分区表执行 alter table ... reorganize partition 或某些带 _split 语义的操作（如 tidb 的 split region、或自定义分表逻辑中模拟的“拆分”）时，底层往往需要重建目标分区的数据结构。innodb 默认会对涉及的分区加 x 锁，而很多版本和引擎实现中，这个操作会升级为对整个表加 mdl（metadata lock） 写锁——导致所有 dml 阻塞。

• 不是“只锁要拆的分区”，而是锁整个表元数据，哪怕你只动 p202406
• TiDB 虽无传统表锁，但 SPLIT REGION 若在热点 Region 上执行，仍会触发调度阻塞和写放大，间接造成写延迟飙升
• PostgreSQL 的分区表（v10+）用 ATTACH/DETACH 拆分，本身不锁全表，但若依赖 INSERT ... SELECT 迁移旧数据，就可能因长事务锁住源分区

如何避免 _SPLIT 过程中业务写入中断

核心思路是把“拆分”从原子 DDL 操作，变成可灰度、可回滚、不依赖全局锁的数据迁移流程。

• 提前建好新分区（或新物理表），用 CREATE TABLE ... PARTITION BY ... 或 CREATE TABLE LIKE 复制结构，不带数据
• 通过应用层双写或 TRIGGER + binlog 解析 同步增量：老分区继续接收写入，同时将新数据实时写入新分区
• 等存量数据迁移完成（可用 pt-archiver 或自定义批处理），再用 RENAME TABLE 原子切换（仅毫秒级 MDL），而不是直接 REORGANIZE
• MySQL 8.0.29+ 支持 ALTER TABLE ... EXCHANGE PARTITION 无锁交换，但要求表结构完全一致、且目标分区为空——适合预分配场景

_SPLIT 期间高并发读写冲突的典型表现

锁表只是表象，真正让服务雪崩的是资源争抢叠加等待链：

• 大量 Waiting for table metadata lock 状态堆积，SHOW PROCESSLIST 里能看到上百个 alter 和 insert 卡住
• 连接数暴涨，触发 max_connections 限制，新请求连不上
• TiDB 中出现 Region is unavailable 或 write stall 日志，Prometheus 上 tikv_scheduler_pending_tasks_total 持续上升
• PostgreSQL 中 pg_locks 显示大量 AccessExclusiveLock 在父表上，即使你只操作子分区

不同数据库对 _SPLIT 的兼容性与替代方案

没有银弹，得按实际栈选路径：

• MySQL：放弃原生 REORGANIZE，改用 pt-online-schema-change --chunk-index 拆分，它通过触发器捕获变更，但要注意触发器性能损耗
• TiDB：优先用 SPLIT REGION TABLE t BETWEEN (0) AND (1000000) REGIONS 4，配合 tidb_enable_table_partition = 'on'，并确保 split-region-max-rate 不设过高（默认 2）
• PostgreSQL：用 CREATE TABLE t_202407 PARTITION OF t FOR VALUES FROM ('2024-07-01') TO ('2024-08-01') 动态加分区，再用 INSERT INTO t_202407 SELECT ... FROM t WHERE ... 迁移，全程不锁主表（只锁对应子表）
• 如果用 MyCat/ShardingSphere 这类中间件，_SPLIT 实际是逻辑操作，真正风险在后端分片 DB 的 DDL 执行时机——必须配置 allow-runtime-add-table 并关闭自动同步 DDL

真正麻烦的从来不是“怎么拆”，而是“怎么让拆的时候没人感知”。DDL 可以重试，用户请求超时就直接失败。所以所有方案都要预留 fallback：比如双写开关、影子表回切 SQL、binlog 回滚位点记录——这些比选对函数名重要得多。