【TiDB 版本】 V6.1 （V5.4升级而来）

【问题描述】一个约1.5亿的表，Healthy为0.
show analyze status; 基本都是这个表收集失败的信息，一直在收集。
tidb_gc_life_time参数已经从默认的10m调整到了60m，还是收集失败。这个参数也不可能一直不断调整啊。如果生产多几个这种大表，咋整呢？

    MySQL [XX]> select count(0) from expr08_crst_lg_cust_temp;
    +-----------+
    | count(0)  |
    +-----------+
    | 146690000 |
    +-----------+
    1 row in set (6.29 sec)

    MySQL [XX]> show stats_healthy where table_name='expr08_crst_lg_cust_temp';
    +---------+--------------------------+----------------+---------+
    | Db_name | Table_name               | Partition_name | Healthy |
    +---------+--------------------------+----------------+---------+
    | XXX    | expr08_crst_lg_cust_temp |                |       0 |
    +---------+--------------------------+----------------+---------+
    1 row in set (0.01 sec)

image1982×648 491 KB

现在手动跑下试试。

1）gc设置大一点，如报错的一样，原因很明显；
2）anaylze的并行度设置大一点，注意可能对增加系统的负载；

手动收集和自动收集的差距在哪？为啥手动这么快？
慢日志截图：

image2240×710 223 KB

你这个内存800m 很容易超过1g 终止了

那个参数已经改过了。超过写disk

TiDB统计信息原理简介与实践

主要是因为tidb 自动收集统计信息，下面的统计信息参数都设置成1 了，建议大表都手工设置定时任务去收集
查看当前值
mysql> show variables like ‘tidb_build_stats_concurrency’;
±-----------------------------±------+
| Variable_name | Value |
±-----------------------------±------+
| tidb_build_stats_concurrency | 4 |
±-----------------------------±------+
1 row in set (0.00 sec)

mysql> show variables like ‘tidb_distsql_scan_concurrency’;
±------------------------------±------+
| Variable_name | Value |
±------------------------------±------+
| tidb_distsql_scan_concurrency | 15 |
±------------------------------±------+
1 row in set (0.00 sec)

mysql> show variables like ‘tidb_index_serial_scan_concurrency’;
±-----------------------------------±------+
| Variable_name | Value |
±-----------------------------------±------+
| tidb_index_serial_scan_concurrency | 1 |
±-----------------------------------±------+
1 row in set (0.01 sec)

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