为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
- 【TiDB 版本】:v3.06
- 【问题描述】:发现集群响应时间变慢了很多
查询慢sql发现狠多sql的索引都走的不太对,导致原本查询很快的sql变慢了,持续了10分钟左右,tidb又恢复正常了,再执行之前慢sql发现索引都走对了,执行也快了,不知道是什么原因导致原本正常的sql突然执行变慢了,索引走的不正确
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。
为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。
若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。
show stats_meta where table_name=‘designmaterial’; ---->注意大小写和原表一致,返回结果
查看变量值
select @@tidb_auto_analyze_ratio;
select @@tidb_auto_analyze_start_time;
select @@tidb_auto_analyze_end_time;
三个变量的值都是空的
请查看当前表的健康度
SHOW STATS_HEALTHY where table_name=‘designmaterial’;
参考文档,这三个参数是控制自动收集的,是否有改过参数配置? 不让自动收集,会设置定时任务,定时收集统计信息?
当某个表 tbl
的修改行数与总行数的比值大于 tidb_auto_analyze_ratio
,并且当前时间在 tidb_auto_analyze_start_time
和 tidb_auto_analyze_end_time
之间时,TiDB 会在后台执行 ANALYZE TABLE tbl
语句自动更新这个表的统计信息
65194420 * 0.5 = 32597210 达到这么多时,会自动更新统计信息。
看当前的modify_count 为 19590, 请问这张表新增大概是多少记录?
修改和新增的数据不会有这么多
这部分qps好像是analyze dm同步checkpoint表的
我是查询慢sql有索引字段记录
现在是正常的,偶尔会有走错这种现象,生产上这样出现就是生产故障了,不知道是什么因素能导致tidb走错索引
这个猜测是统计信息不准确,正好重新收集了,所以准确了。
建议你可以定期手工收集。
之后新版本可以使用 SPM 固定执行计划