2500多万的表加联合索引卡死两次

[Hacker_QgXEs8he (heming@emar)]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】

【概述】 场景 + 问题概述

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 JOB_ID DB_NAME TABLE_NAME JOB_TYPE SCHEMA_STATE SCHEMA_ID TABLE_ID ROW_COUNT START_TIME END_TIME STATE
19596 yixintui_operate Agent_material_report_cost add index write reorganization 1382 14314 23417136 2021-09-16 22:56:19 NULL running
heming 9:07:16
mysql> alter table Agent_material_report_cost add key Report_Date_Platform_Type(Report_Date,Platform_Type);
这个索引创建 一个晚上没成功 ，昨天下午也是创建到 2360多万 就卡死了
【统计信息是否最新】

    【执行计划内容】

    【 SQL 文本、schema 以及 数据分布】

【业务影响】

【TiDB 版本】
5.1.1
【附件】 相关日志及监控（https://metricstool.pingcap.com/)

• TiUP Cluster Display 信息
• TiUP CLuster Edit config 信息
• TiDB-Overview Grafana监控
• TiDB Grafana 监控
• TiKV Grafana 监控
• PD Grafana 监控
• 对应模块日志（包含问题前后 1 小时日志）

[这道题我不会 (Lizhengyang@PingCAP)]

看下卡死的时间点集群是否压力很大，如果是的话可以考虑降低下创建索引的并发度，调低下参数 tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt

[Hacker_QgXEs8he (heming@emar)]

压力不大 ， 已经14个小时了 ，还是 2344多万 我已经cancel了 打算重新导入新的表里了

很多时间系统压力很低

[leeray (Lileiaab)]

建索引理论速度可以达到15w行每秒。

集群压力不到的话加大参数试试。 tidb_ddl_reorg_batch_size 和 tidb_ddl_reorg_worker_cnt
建索引对磁盘IO消耗很大，你看集群cpu，内存不太能反映问题。去看一下grafana io相关监控。看看是不是磁盘io满了。

[Hacker_QgXEs8he (heming@emar)]

mysql> show variables like ‘tidb_ddl%’;
±---------------------------±-------------+
| Variable_name | Value |
±---------------------------±-------------+
| tidb_ddl_error_count_limit | 512 |
| tidb_ddl_reorg_batch_size | 1024 |
| tidb_ddl_reorg_priority | PRIORITY_LOW |
| tidb_ddl_reorg_worker_cnt | 16 |
感觉不是参数的问题 。 别的表都正常 ，就这个表 两次 都卡死 ，中间有个别的表2亿的加索引没问题。

[这道题我不会 (Lizhengyang@PingCAP)]

这张表和索引创建成功的 2 亿那张表有啥区别吗？麻烦把表结构和创建索引的语句发出来看下，另外看下 tidb ddl owner 节点的日志中有无什么报错或提示信息。