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

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 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 小时日志)

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

2赞

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


很多时间系统压力很低
image

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

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

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亿的加索引没问题。

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