投票：生产环境是否敢在业务高峰期执行 DDL？

🪐 TiDB 技术问题
1

说说你们团队的 DDL 运维规范，哪些 DDL 是绝对的 “高危操作”？

2

不会，不敢

3

我踩过比较深的坑是大批量 delete 不拆分会卡住 GC，导致 TiKV 磁盘空间一直涨。后来把 delete 拆成每批 5000 行，配合 sleep 间隔就好了。还有 DDL 操作尽量在低峰期做，加索引会用 INGEST 模式。

4

那肯定不行呀！ ddl 要低峰期在搞

5

测试环境可以随意

6

TiDB不是支持在线DDL吗，不阻塞读写，按照官方的说法，业务高峰期执行没问题。关键取决于表数量的多少。

1 个赞
7

不是所有业务都有低峰期的，主要还是硬件配置需要一定冗余。

8

看什么类型吧，类似加字段这种是几乎不影响的，当然能低峰期还是低峰期执行更好

9

如果非得高峰期进行，那肯定请示领导才行。自己不主动干。

12

有道理，毕竟服务器的资源是有效的。

13

我踩过比较深的坑是大批量 delete 不拆分会卡住 GC，导致 TiKV 磁盘空间一直涨。后来把 delete 拆成每批 5000 行，配合 sleep 间隔就好了。还有 DDL 操作尽量在低峰期做，加索引会用 INGEST 模式。

14

我踩过比较深的坑是大批量 delete 不拆分会卡住 GC，导致 TiKV 磁盘空间一直涨。后来把 delete 拆成每批 5000 行，配合 sleep 间隔就好了。还有 DDL 操作尽量在低峰期做，加索引会用 INGEST 模式。

15

不敢不敢

16

大批量整表 DELETE 不拆分，长期阻塞 GC 推进，历史版本堆积、磁盘持续暴涨；优化方案是拆分分批删除，单次控制 5000 条，批次中间加休眠间隔，GC 即可正常回收空间。另外 DDL 优选业务低峰执行，新增索引优先启用INGEST 快速导入模式，规避在线资源抖动。

17

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。