TiDB走错索引&统计信息收集失败Query execution was interrupted

【 TiDB 使用环境】
生产环境 ,TiDB版本6.1.5

【 问题描述】
3.28号下午业务应用有跑update任务,走错索引,tidb计算节点持续发生oom


排查该表统计信息55,不是最优,手动收集该表统计信息;

mysql> SHOW STATS_HEALTHY where table_name like 'xxxx';
+----------------+------------------+----------------+---------+
| Db_name        | Table_name       | Partition_name | Healthy |
+----------------+------------------+----------------+---------+
| xxxx  | xxx  |                |      55 |
+----------------+------------------+----------------+---------+

统计信息版本为1
mysql>  show global variables like '%tidb_analyze_version%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| tidb_analyze_version | 1     |
+----------------------+-------+
1 row in set (0.00 sec)



该表数据量约66亿,数据+索引2.4T

凌晨5点半统计信息收集失败报错[executor:1317]Query execution was interrupted,凌晨失败收集统计信息的tidb计算节点内存稳定不高

早上手动收集表指定联合索引统计信息(进行中未失败)ANALYZE TABLE xxx INDEX idx_standard_data_ct_vid_dt_sid;

未走到正确时间索引的流线热力图

表太大,统计信息收集不动,建议 https://docs.pingcap.com/zh/tidb/v5.4/statistics#全量收集
参考这里,我觉得应该按照比例收集。例如WITH 0.1 SAMPLERATE只收集10%的数据。
另外建议修改analyze的并发度

适当调大一点,不要影响生产应用。

并发是早上已经增大4倍多到18了 :rofl:


mysql>  show global variables like '%tidb_build_stats_concurrency%';                                                                                                                                           +------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| tidb_build_stats_concurrency | 18    |
+------------------------------+-------+

其实可以加 bind 来解决你这个问题,至少先让执行计划走对:https://docs.pingcap.com/zh/tidb/stable/sql-statement-create-binding

收集比例减低一点,或者直接对应sql使用hint or 绑定执行计划

降一下并发数,日志收集频率降低10倍,试试

  • update 一直没执行过成功,应用程序超时终止了,无法通过历史执行计划来创建binding
  • 根据SQL创建强制索引bind没生效,最后还是收集表索引统计信息完后才走索引正常
 mysql> ANALYZE TABLE xxxx_data INDEX idx_standard_xxxx;

Query OK, 0 rows affected (4 hours 16 min 57.41 sec)
1 个赞

有可能升级下集群版本,后面的版本对统计收集做了很多优化

最大执行时间配置是多少?也可以适当调大些。

image

这个截图的功能是自己开发的? 还是企业版