select count(1) from 表很慢

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】6.5
【复现路径】
【遇到的问题：问题现象及影响】没有安装 tiflash， 10亿数据量的表做select count(1) from 很慢，请问下这是正常现象吗？有什么解决方案？
【资源配置】
【附件：截图/日志/监控】

2

看下tikv资源使用情况。

3

表有主键么？完整语句里有order by等条件么？

4

count(1) 如果没索引就全表了，count(*) 会走主键索引等

5

:thinking:这俩有区别么？感觉实际使用中count(1)和count(*) 效果差不多 ，但我司内部一直认为count(1)比count(*) 效率高。

6

表有联合主键，没有任何条件。select count(*) from d_secondminutedata;

7

执行这个语句看看执行计划
explain analyze select count(*) from d_secondminutedata;

8

试了下是一样的

image
image1026×564 16.4 KB

9

:+1:实践派大佬

10

image
image1960×241 15.3 KB

11

你的资源配置什么样，磁盘什么类型。10亿条 47秒也还可以吧

12

6个kv节点，每台机器都是16核，16g内存。47秒是第二次执行的结果，第一次执行差不多接近200秒

13

我遇到过，如果这个表的DML非常频繁，就会慢。把应用停掉后就秒出结果。
30w左右数据，12s和0.2s的区别。

image
image2138×772 161 KB

14

磁盘呢什么类型，上面的explain analyze的结果上传下 截图有些新看不到

15

把slow log 中这条语句相关的信息上传一下。

16

explain analyze 看看

17

10 亿数据，如果 tikv 不是很忙的话，cpu 足够多还是可以的差不多几秒钟就能 count 完🤔。

18

tidb多大的配置

19

tidb好像在parser层就把count(1)和count(*)划等号了。

20

看我这个，好慢。。。

mysql> explain analyze select /*+ read_from_storage(tikv[lineitem]) */ count(*) from lineitem;
+----------------------------+-------------+----------+-----------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+-----------+------+
| id                         | estRows     | actRows  | task      | access object  | execution info                                                                                                                                                                                                                                                                                                                                                                                   | operator info                     | memory    | disk |
+----------------------------+-------------+----------+-----------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+-----------+------+
| HashAgg_13                 | 1.00        | 1        | root      |                | time:39.4s, loops:2, partial_worker:{wall_time:39.362488482s, concurrency:5, task_num:1, tot_wait:3m16.81108575s, tot_exec:94.27µs, tot_time:3m16.811192801s, max:39.362249552s, p95:39.362249552s}, final_worker:{wall_time:0s, concurrency:5, task_num:1, tot_wait:3m16.811393418s, tot_exec:30.083µs, tot_time:3m16.811426486s, max:39.362296841s, p95:39.362296841s}                         | funcs:count(Column#18)->Column#17 | 16.5 KB   | N/A  |
| └─TableReader_14           | 1.00        | 156      | root      |                | time:39.4s, loops:2, cop_task: {num: 159, max: 7.69s, min: 212.8ms, avg: 3.54s, p95: 7.15s, max_proc_keys: 462798, p95_proc_keys: 462756, tot_proc: 8m47.6s, tot_wait: 33.5s, rpc_num: 159, rpc_time: 9m23.4s, copr_cache_hit_ratio: 0.00, build_task_duration: 274.2µs, max_distsql_concurrency: 15}, backoff{regionMiss: 2ms}                                                                  | data:HashAgg_6                    | 438 Bytes | N/A  |
|   └─HashAgg_6              | 1.00        | 156      | cop[tikv] |                | tikv_task:{proc max:7.2s, min:212ms, avg: 3.32s, p80:5.75s, p95:6.83s, iters:70417, tasks:159}, scan_detail: {total_process_keys: 72080384, total_process_keys_size: 2594893824, total_keys: 73692884, get_snapshot_time: 16.4s, rocksdb: {delete_skipped_count: 130912, key_skipped_count: 73762895, block: {cache_hit_count: 2208, read_count: 455143, read_byte: 4.43 GB, read_time: 5.11s}}} | funcs:count(1)->Column#18         | N/A       | N/A  |
|     └─TableFullScan_12     | 70899712.00 | 72080384 | cop[tikv] | table:lineitem | tikv_task:{proc max:7.2s, min:211ms, avg: 3.32s, p80:5.75s, p95:6.83s, iters:70417, tasks:159}                                                                                                                                                                                                                                                                                                   | keep order:false                  | N/A       | N/A  |
+----------------------------+-------------+----------+-----------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+-----------+------+
4 rows in set (39.36 sec)

主要慢的点：
1、copr_cache_hit_ratio=0，没有命中tidb侧的缓存。
2、get_snapshot_time: 16.4s，不知道为啥这么慢。。。
3、read_byte: 4.43 GB, read_time: 5.11s，发生了物理读。
4、tablescan慢，我理解的是：time:39.4s - get_snapshot_time: 16.4s - read_time: 5.11s = 17.89s
17.89s * 15 / tasks:159 = 1.69s，纯内存读取数据一个region平均花费1.69秒，感觉好慢。。
当时在加载并发加载数据，应该是CPU不足导致。但是get_snapshot_time为何这么慢啊？

有时候15个task一起干活才勉强干得过传统数据库一个干活的。感觉tikv的数据读取扫描效率不高啊。