聊聊大家生产上踩过最痛的 TiDB 坑？我先来：分区 REORGANIZE 炸 CPU + 锁雪崩

[Fanchen (Ti D Ber Uoi Hnf Zw)]

最近生产因为一次 REORGANIZE PARTITION 批量拆分分区，直接单 TiKV CPU 打满，引发全库锁超时、非分区表事务也全部阻塞。

想问问大家：

1. 你们生产遇到过最致命的 TiDB 故障是什么？
2. 哪些 DDL/SQL 是绝对不能在生产高峰期执行的？
3. 分区表维护你们现在的标准规范是什么？

欢迎大佬交流踩坑经验！

[TiDBer_odwPM8gO]

分区拆分等高负载 DDL 极易引发节点资源瓶颈、全局事务阻塞，高峰期严禁执行分区维护、大表变更类操作。

[wbslxw (Ti D Ber Cl S0j Eng)]

生产高峰禁止分区重组、大表 DDL，分区维护统一安排低峰窗口，规避资源打满与事务阻塞风险。

[yg_2024 (yangguang)]

1. 哪些 DDL/SQL 是绝对不能在生产高峰期执行的？
   都不做，除非评估确有必要且风险可控（小表紧急创建索引）。

[Augenstern]

（一）DDL 类：业务高峰（9:00-23:00）完全禁止

1. 分区表高危 DDL

1. ALTER TABLE ... REORGANIZE PARTITION 拆分 / 合并分区（最高危，你的故障类型）
2. ALTER TABLE ... MOVE PARTITION 迁移分区数据
3. 批量 DROP PARTITION（一次性删除 3 个及以上分区）
4. ALTER TABLE ... COALESCE PARTITION 合并分区

2. 大表结构变更 DDL

1. ADD COLUMN ... DEFAULT xxx（非 NULL 默认值，全表重写）
2. DROP INDEX / ADD INDEX 千万行以上大表新建 / 删除索引
3. TRUNCATE TABLE 业务核心大表（瞬间清空 Region，GC 风暴）
4. OPTIMIZE TABLE 任意千万行表
5. ALTER TABLE FORCE 强制重建表数据

3. 集群 / 表全局操作

1. ANALYZE TABLE 无采样限制、亿级大表全量统计（Coprocessor 打满 TiKV）
2. 并发提交多条重量级 DDL（REORG、加索引、新增字段）

（二）SQL 类：高峰期严格拦截，禁止上线 / 手动执行

1. 无过滤条件全表 UPDATE、DELETE（update t set a=1;）
2. 不带 limit 亿级分页查询、无索引大表全表 SELECT
3. 超大事务：单次 DML 影响行数超 10w 行，批量导入不拆分 batch
4. 大批量 LOAD DATA、INSERT ... SELECT 跨分区拷贝数据
5. 长时间未提交长事务（超过 30s，占用行锁、阻塞 GC）

[TiDBer_gzy (Ti D Ber 3ix3 Rp1 H)]

最好别在跑批的时候做

[独善其身 (Ti D Ber Bi Rqfz5 K)]

找业务量空闲的时候搞ddl

[克里克里克 (Ti D Ber H052ej9m)]

你这个是有工具、策略拦截，还是只是制度方面的？

[yg_2024 (yangguang)]

1. 你们生产遇到过最致命的 TiDB 故障是什么？
   tikv磁盘使用率的非常高的情况下，单台服务器出现硬件故障直接宕机。分布式数据库虽然可以保障业务连续，但是如果不进行干预的话，半个小时后tikv会自动补副本，进一步加剧磁盘空间不足的问题。

[yg_2024 (yangguang)]

1. 分区表维护你们现在的标准规范是什么？
   tidb集群，一直没使用分区表。