【TiDBer 唠嗑茶话会 184】分享你最近一次/印象最深的运维 TiDB 时的误操作，最后是怎么解决的？

哈喽沃德
Wed, 15 Oct 2025 06:03:19 +0000

最近一次/印象最深的运维 TiDB 时的误操作】​​

在一次业务高峰期，我需要为一个大表添加索引来优化查询性能。由于时间紧迫，我直接在生产环境执行了 CREATE INDEX语句，没有充分评估影响。结果这个 DDL 操作导致了 TiKV 节点 CPU 使用率飙升，大量慢查询涌现，业务响应时间明显变慢。

​​【最后是怎么解决的】​​

​​紧急干预​​：首先使用 ADMIN CANCEL DDL JOBS <job_id>取消了正在进行的索引创建任务

​​流量降级​​：临时与业务方沟通，降低了部分非核心业务的写入流量

​​择机重做​​：在业务低峰期（凌晨2点）重新执行索引创建，并使用了 ALGORITHM=INPLACE参数减少锁表时间

​​监控恢复​​：密切观察 TiDB Dashboard 和 Grafana 监控指标，确保集群性能恢复正常

​​【给小伙伴们一些避坑建议吧~】​​

​​避开高峰​​：DDL 操作一定要选择业务低峰期进行，提前与业务团队协调时间窗口

​​测试先行​​：在测试环境先验证大表 DDL 操作的影响和耗时

​​使用工具​​：考虑使用 TiDB 的在线 DDL 相关工具或分批次执行策略

​​监控预警​​：操作前设置好告警阈值，操作期间实时关注集群关键指标

​​备份预案​​：重要变更前做好数据备份和回滚预案

这次经历让我深刻体会到，即使是 TiDB 支持在线 DDL，对于大数据量的表操作仍需谨慎规划，做好充分准备才能确保业务稳定性。

符合活动要求的参与格式，期待与各位 TiDBer 交流更多运维经验！

阅读完整话题