大表统计信息收集问题

[TiDBer_Y2d2kiJh]

一个日志表有20亿条数据，现在想将这个表通过ALTER TABLE A RENAME TO B;换表名，请问下这样操作时间会很快吗？这个表已经删除了8500万条数据，想将这个表进行统计信息收集，会不会要很长时间？

【TiDB 使用环境】生产环境
【TiDB 版本】V5.4.0
【部署方式】机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
通过delete from A where sj < ‘2025-01-01’ limit 10000;删除数据。
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

[万仞听松 (Ti D Ber Ztf5y Jyk)]

改表名跟数据量没关系吧。

[万仞听松 (Ti D Ber Ztf5y Jyk)]

通常默认会自动收集统计信息，一般情况不需要手工收集

[万仞听松 (Ti D Ber Ztf5y Jyk)]

手工收集的速度跟数据量，采样率等有关系

[Kongdom]

RENAME都是秒级的，统计信息收集高版本比较快，v5的话，会慢一些。

[随缘天空 (Ti D Ber Ivw R7o Pj)]

RENAME TABLE 在 TiDB 中是元数据操作（DDL），不涉及数据移动或重写。 无论表有 1 行还是 20 亿行，耗时都差不多

[tidb菜鸟一只 (小菜一颗)]

rename很快，大表收集统计信息的话建议手工收集一下看看
SET tidb_build_stats_concurrency=16;
SET tidb_distsql_scan_concurrency =64;
ANALYZE TABLE table_name WITH 0.1 SAMPLERATE;—收集10%的统计信息

[TiDBer_Ejh0eCXc]

rename很快. 这么大的表统计更新可能会引发 TiKV 的大量读取压力和 TiDB Server 的 CPU 计算压力,甚至OOM. 建议增量统计更新. 开启auto analyze. 或者没人用时候执行
– 1. 先执行重命名（很快）
ALTER TABLE A RENAME TO B;

– 2. 在低峰期执行统计信息收集
– 建议调整并发度，避免把集群跑满
SET SESSION tidb_build_stats_concurrency = 4; – 根据集群配置调整，降低并发
SET SESSION tidb_distsql_scan_concurrency = 8; – 增加扫描并发

– 执行收集（这一步会很慢）
ANALYZE TABLE B;

[独善其身 (Ti D Ber Bi Rqfz5 K)]

delete数据量如果比较大的话,GC应该会耗费很大资源.统计信息我感觉不会耗费太大资源

[wbslxw (Ti D Ber Cl S0j Eng)]

换表名与数据量没有关系， 在 TiDB 中，表重命名是元数据操作，仅修改 PD 中存储的表名映射，不涉及任何数据文件的移动或修改。

[Augenstern]

• 表重命名：ALTER TABLE RENAME TO 是元数据操作，毫秒级完成，生产环境可随时执行（避开长查询即可）；
• 统计信息收集：耗时较长（几十分钟到数小时），核心优化手段是「调低采样率 + 仅分析核心列 + 分区表分批分析」，且必须在业务低峰期执行；
• 额外建议：若该日志表以归档为主，可考虑 TiDB 的 ALTER TABLE ... COMPACT 压缩数据后再分析，进一步减少扫描耗时

[zhanggame1 (Ti D Ber G I13ecx U)]

表有自己的唯一id的，改名字不会改id，所以很快

[TiDBer_Ejh0eCXc]

可以按分区做统计更新, 这样好一点

[suyh1988 (Ti D Ber Cte Vr F8 O)]

rename只涉及元数据修改，很快完成的。

[Royce1220 (Ti D Ber Kwxb3 N7 I)]

rename都是立刻完成的吧

[TiDBer_Ejh0eCXc]

建议规划升级到更新的 TiDB 版本（如 v6.5 或 v7.0+），新版本在统计信息收集效率上有很大提升

[Kongdom]

是的，立刻完成的。