执行计划在健康度99的情况下出现大量pseudo estimation

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
v4.0.12

【概述】 场景 + 问题概述
执行计划在一段时间内出现大量pseudo estimation,想问一下出现的原因以及如何解决

SQL Statement

SELECT
  nsfw_flag,
  hidden_slr_flag,
  delayed_item_index_time,
  item_id AS item_id,
  (?) AS is_suppression
FROM
  uis_item_store
WHERE
  item_id = ?

TiDB Dashboard上看到SQL的执行计划

	id                   	task     	estRows   	operator info                                                                                                                                         	actRows	execution info                                                                                                                                           	memory   	disk
	Projection_4         	root     	2522313.58	uis.uis_item_store.nsfw_flag, uis.uis_item_store.hidden_slr_flag, uis.uis_item_store.delayed_item_index_time, uis.uis_item_store.item_id, 1->Column#85	0      	time:949.6µs, loops:1, Concurrency:4                                                                                                                    	13.1 KB  	N/A
	└─IndexLookUp_13     	root     	2522313.58	                                                                                                                                                      	0      	time:888.8µs, loops:1,  table_task: {total_time: 3.29ms, num: 0, concurrency: 4}                                                                        	208 Bytes	N/A
	  ├─IndexRangeScan_11	cop[tikv]	2522313.58	table:uis_item_store, index:PRIMARY(item_id, item_vrtn_id), range:[313600556967,313600556967], keep order:false, stats:pseudo                         	0      	time:802.9µs, loops:1, cop_task: {num: 1, max: 773.8µs, proc_keys: 0, rpc_num: 1, rpc_time: 762µs, copr_cache: disabled}, tikv_task:{time:0s, loops:1}	N/A      	N/A
	  └─TableRowIDScan_12	cop[tikv]	2522313.58	table:uis_item_store, keep order:false, stats:pseudo                                                                                                  	0      	                                                                                                                                                         	N/A      	N/A

Explain看到的plan

+----------------------------------+---------+-----------+------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| id                               | estRows | task      | access object                                              | operator info                                                                                                                                          |
+----------------------------------+---------+-----------+------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| Projection_4                     | 2.00    | root      |                                                            | uis.uis_item_store.nsfw_flag, uis.uis_item_store.hidden_slr_flag, uis.uis_item_store.delayed_item_index_time, uis.uis_item_store.item_id, 1->Column#85 |
| └─IndexLookUp_13                 | 2.00    | root      |                                                            |                                                                                                                                                        |
|   ├─IndexRangeScan_11(Build)     | 2.00    | cop[tikv] | table:uis_item_store, index:PRIMARY(item_id, item_vrtn_id) | range:[184422774490,184422774490], keep order:false                                                                                                    |
|   └─TableRowIDScan_12(Probe)     | 2.00    | cop[tikv] | table:uis_item_store                                       | keep order:false                                                                                                                                       |
+----------------------------------+---------+-----------+------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+

可以看到使用pseudo和使用实际的统计信息差距明显,看了一下统计信息健康度在99

mysql> show stats_healthy;

+------------------+-------------------------------------+----------------+---------+
| Db_name          | Table_name                          | Partition_name | Healthy |
+------------------+-------------------------------------+----------------+---------+
| uis              | uis_item_store                      |                |      99 |

Grafana上看到有一段时间所有SQL都在使用Pesudo Estimation
image
tidb1-TiDB_2021-07-20T06_45_10.582Z.json (165.3 KB)

顺便问一下关于auto analyze,我看这里说一分钟之内没有写入才会触发auto analyze,是不是意味着如果表有持续的写入就不会进行auto analyze?如果我希望在持续写入的情况下tidb每隔一段时间做一下auto analyze需要怎么做

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题,参考 AskTUG 的 Troubleshooting 读性能慢-慢语句

【统计信息是否最新】

    【执行计划内容】

    【 SQL 文本、schema 以及 数据分布】

【业务影响】

【TiDB 版本】

【附件】 相关日志及监控(https://metricstool.pingcap.com/)

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

你可以参考下:

https://docs.pingcap.com/zh/tidb/v4.0/statistics#自动更新
https://docs.pingcap.com/zh/tidb/v4.0/troubleshoot-cpu-issues#tidb-执行计划不对导致延迟增高
https://book.tidb.io/session4/chapter6/sql-optimization-cases.html#案例2-执行计划不稳定导致查询延迟增加

analyze 对性能还是有比较大的影响的,一般都是建议定时触发

  • 手动 analyze table,配合 crontab 定期 analyze,维持统计信息准确度

我可以理解为,不建议auto analyze,建议使用crontab手动定时触发analyze吗?

另外这个好像没有解决主要问题,也就是为什么在统计信息基本准确的情况下会出现大量甚至全量的pesudo estimation

查下这个参数,是不是默认的

另外:

在 TiDB 中 auto analyze 的触发策略是怎样的?

触发策略:新表达到 1000 条,并且在 1 分钟内没有写入,会自动触发。

当表的(修改数/当前总行数)大于 tidb_auto_analyze_ratio 的时候,会自动触发 analyze 语句。 tidb_auto_analyze_ratio 的默认值为 0.5,即默认开启此功能。为了保险起见,在开启此功能的时候,保证了其最小值为 0.3。但是不能大于等于 pseudo-estimate-ratio (默认值为 0.8),否则会有一段时间使用 pseudo 统计信息,建议设置值为 0.5。

1分钟应该是指的新表。

pseudo-estimate-ratio没有出现在config内,应该是默认值

# WARNING: This file is auto-generated. Do not edit! All your modification will be overwritten!
# You can use 'tiup cluster edit-config' and 'tiup cluster reload' to update the configuration
# All configuration items you want to change can be added to:
# server_configs:
#   tidb:
#     aa.b1.c3: value
#     aa.b2.c4: value
enable-telemetry = false

[isolation-read]
engines = ["tikv", "tidb"]

[log]
level = "info"
slow-query-file = "tidb-slow.log"
tidb.toml (END)

请问新表的定义是什么?我疑惑的点在于,为什么auto analyze会只对新表应用这个逻辑,听上去表的新或者老不是影响执行auto analyze的理由

有点绕,不过 我理解是 auto analyze 动作会针对“新/旧” 2 种不同类型的表,分别有不同的触发条件(但怎么定义新旧,这里我也不太清楚,严格的定义逻辑)
1、不过我觉得需要确认2个事情,发生 pseudo 的时候,统计信息健康度是 99?
2、tidb-server 日志,应该会有收集统计信息的日志(可以看一下,有无有用信息)
3、其他方面的资料解释,我建议看看 其他 两位同学给的链接

我理解的是没有数据的表,新表只有插入没有修改。所以新表是按插入触发自动收集,旧表是按修改触发自动收集。

1、不过我觉得需要确认2个事情,发生 pseudo 的时候,统计信息健康度是 99?

请问能看得到stats health的历史吗,从pseudo estimation ops上看每天都会有几个小时有比较明显的流量

另外如果我把pseudo-estimate-ratio调成1的话,是不是就不会使用pseudo,最多使用老的统计信息?

2、tidb-server 日志,应该会有收集统计信息的日志(可以看一下,有无有用信息)

目前没看到很明显的异常

1、不能看到历史信息,这个值 其实默认值就比较大了,建议看看是否需要添加手动收集统计信息。hint 、spm 的方式来解决问题(解决问题是重点吧,原因可以放在第二)
2、日志不是说异常,就是想看看有没有收集统计信息的动作