业务从 4.0.10 集群切换到 7.5.1 集群后性能不理想

rebelsre · 2024 年5 月 30 日 08:14

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.5.1
【复现路径】

SELECT
  *
FROM
  xxx
WHERE
  next_run_time <= ?
  AND id > ?
  AND account_monitor_type_id = ?
  AND remark = ?
  AND state = ?
ORDER BY
  id
LIMIT
  ? [arguments: (1717055486, 0, "11", "3", 1, 1000)];

【遇到的问题：问题现象及影响】
select 语句诱发慢查询导致整体 P99 延迟高
【资源配置】

【附件：截图/日志/监控】
执行计划

| id                           | estRows   | estCost      | actRows  | task      | access object                                                                              | execution info                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | operator info                                                                                                                                                                                                            | memory  | disk  |
| Limit_13                     | 1000.00   | 393430501.48 | 403      | root      |                                                                                            | time:1m33.2s, loops:2                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | offset:0, count:1000                                                                                                                                                                                                     | N/A     | N/A   |
| └─IndexLookUp_47             | 1000.00   | 393430501.48 | 403      | root      |                                                                                            | time:1m33.2s, loops:2, index_task: {total_time: 1m32.8s, fetch_handle: 1.74s, build: 3.23s, wait: 1m27.8s}, table_task: {total_time: 7m45.2s, num: 657, concurrency: 5}, next: {wait_index: 8.32ms, wait_table_lookup_build: 402.1µs, wait_table_lookup_resp: 1m33.2s}                                                                                                                                                                                                                                                                                                                                                                                                                                     |                                                                                                                                                                                                                          | 24.4 MB | N/A   |
|   ├─IndexRangeScan_44(Build) | 200660.78 | 40834468.62  | 13366428 | cop[tikv] | table:t_rhino_monitor_wemedia_user, index:account_monitor_type_id(account_monitor_type_id) | time:68.9ms, loops:13098, cop_task: {num: 452, max: 153.5ms, min: 1.04ms, avg: 14.9ms, p95: 74.7ms, max_proc_keys: 50144, p95_proc_keys: 50144, tot_proc: 4.76s, tot_wait: 103ms, rpc_num: 452, rpc_time: 6.72s, copr_cache_hit_ratio: 0.67, build_task_duration: 205.6µs, max_distsql_concurrency: 2}, tikv_task:{proc max:134ms, min:0s, avg: 34.2ms, p80:58ms, p95:73ms, iters:14847, tasks:452}, scan_detail: {total_process_keys: 4180992, total_process_keys_size: 192325632, total_keys: 4918093, get_snapshot_time: 32.2ms, rocksdb: {delete_skipped_count: 68, key_skipped_count: 4917946, block: {cache_hit_count: 7466, read_count: 1, read_byte: 16.0 KB, read_time: 56.4µs}}}                 | range:(11 0,11 +inf], keep order:true                                                                                                                                                                                    | N/A     | N/A   |
|   └─Selection_46(Probe)      | 1000.00   | 91856163.66  | 403      | cop[tikv] |                                                                                            | time:7m42.6s, loops:727, cop_task: {num: 689, max: 10s, min: 4.59ms, avg: 675.4ms, p95: 4.89s, max_proc_keys: 20936, p95_proc_keys: 20480, tot_proc: 3m45.3s, tot_wait: 172.9ms, rpc_num: 689, rpc_time: 7m45.3s, copr_cache_hit_ratio: 0.00, build_task_duration: 218.5ms, max_distsql_concurrency: 2}, tikv_task:{proc max:9.95s, min:3ms, avg: 658.5ms, p80:619ms, p95:4.84s, iters:16451, tasks:689}, scan_detail: {total_process_keys: 13366428, total_process_keys_size: 1576436660, total_keys: 17280280, get_snapshot_time: 63.6ms, rocksdb: {delete_skipped_count: 460, key_skipped_count: 14413892, block: {cache_hit_count: 21214777, read_count: 22, read_byte: 574.4 KB, read_time: 4.68ms}}} | eq(dt_datastory_rhino_kol.t_rhino_monitor_wemedia_user.remark, "3"), eq(dt_datastory_rhino_kol.t_rhino_monitor_wemedia_user.state, 1), le(dt_datastory_rhino_kol.t_rhino_monitor_wemedia_user.next_run_time, 1717055486) | N/A     | N/A   |
|     └─TableRowIDScan_45      | 200660.78 | 61817244.69  | 13366428 | cop[tikv] | table:t_rhino_monitor_wemedia_user                                                         | tikv_task:{proc max:9.94s, min:3ms, avg: 654.9ms, p80:615ms, p95:4.84s, iters:16451, tasks:689}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | keep order:false                                                                                                                                                                                                         | N/A     | N/A   |

kkpeter · 2024 年5 月 30 日 08:22

1000万里面筛出400条，你索引不合理

我是人间不清醒 · 2024 年5 月 30 日 08:24

account_monitor_type_id 这个命中的索引后还有1kw的数据。next_run_time 这个有索引么

TiDB_C罗 · 2024 年5 月 30 日 08:29

看看表结构

TiDBer_C33 · 2024 年5 月 30 日 08:29

索引过滤性太差，最好是建立下联合索引

rebelsre · 2024 年5 月 30 日 08:30

+-------------------------+------------------+------+------+-------------------+-----------------------------------------------+
| Field                   | Type             | Null | Key  | Default           | Extra                                         |
+-------------------------+------------------+------+------+-------------------+-----------------------------------------------+
| id                      | bigint(20)       | NO   | PRI  | NULL              | auto_increment                                |
| init_seed_value         | varchar(255)     | NO   | MUL  | NULL              |                                               |
| interval                | int(10) unsigned | YES  |      | NULL              |                                               |
| next_run_time           | int(10) unsigned | YES  | MUL  | NULL              |                                               |
| account_monitor_type_id | int(11)          | YES  | MUL  | NULL              |                                               |
| state                   | tinyint(4)       | YES  |      | 1                 |                                               |
| create_date             | datetime         | YES  |      | CURRENT_TIMESTAMP |                                               |
| update_date             | datetime         | YES  |      | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP |
| lose_tolerance_level    | tinyint(4)       | YES  |      | NULL              |                                               |
| remark                  | text             | YES  |      | NULL              |                                               |
| is_dynamic              | tinyint(4)       | YES  |      | 1                 |                                               |
| last_run_time           | int(10) unsigned | YES  |      | NULL              |                                               |
| augment_date            | varchar(255)     | YES  |      | NULL              |                                               |
+-------------------------+------------------+------+------+-------------------+-----------------------------------------------+

TiDB_C罗 · 2024 年5 月 30 日 08:33

show create table xxx更好，里面有索引信息

caiyfc · 2024 年5 月 30 日 08:34

索引问题，tikv通过索引account_monitor_type_id，扫描了13366428个key，所以你能看到unified read pool cpu非常的高。合理规划索引，减少key的扫描就没问题了

TiDB_C罗 · 2024 年5 月 30 日 08:36

可以试试重建一下索引，一定要先创建后删除，还有排除服务里有没有用索引名的查询：
1.创建同列，索引名不同
2.再删除老的索引

有猫万事足 · 2024 年5 月 30 日 08:56

只有

AND account_monitor_type_id = ?

这个条件命中了索引。
而剩下的条件大部分在selection算子里面过滤的。

h5n1 · 2024 年5 月 30 日 08:58

1、索引问题看看是否有更好的索引
2、 limit 没下推，应该是有些参数升级后没打开或者统计信息问题，试试手工执行SELECT /*+ LIMIT_TO_COP() */

Jellybean · 2024 年5 月 30 日 09:03

如同上面各位大佬所言，索引过滤后还要扫码1336万行进行回表，这么多数据显然会慢。
楼主检查下索引使用是否合理，如果索引没用对的话，可以尝试analyze一下表，或者force index强制使用索引；如果没用错索引的话，那么这个问题在升级之前应该也会存在，可以拉大监控面板确认，然后也还是需要优化下索引（加索引或重新指定）。

rebelsre · 2024 年5 月 30 日 09:08

这次是搭建全新的 7.5.1 集群，不是升级上来的，是通过cdc增量切换到新集群，确实问题在旧集群也会，但那会还没这么高的耗时，迁移后大概多了一倍的耗时
analyze 操作过但效果不明显
已经加了个联合索引，目前观察中

zhaokede · 2024 年5 月 30 日 09:10

老版本上没有问题吗同一个SQL

zhaokede · 2024 年5 月 30 日 09:10

执行计划是否相同

TiDBer_C33 · 2024 年5 月 30 日 09:17

总共就400条数据，limit1000，下推也没啥用吧

tidb菜鸟一只 · 2024 年5 月 31 日 07:46

delete_skipped_count和key_skipped_count代表的是你删除后的数据是否被gc和compact，如果还没gc或者compact，由于tidb的mvcc机制，他还是会扫到的，虽然不会返回，但是扫描这些数据也需要时间，当你gc或compact完成，这些垃圾数据不再扫描到的时候，查询就会变快了。。。
你现在sql慢主要是因为你新集群没被compact的数据太多了，你上老集群执行下sql看下key_skipped_count是不是比新集群少的多。
可以的话，你可以新集群做下compact，单独针对这个表做就可以。

rebelsre · 2024 年6 月 3 日 06:40

是 tikv 不是 tiflash，我看了下这个 compact 只能用在 tiflash 吧

tidb菜鸟一只 · 2024 年6 月 3 日 09:22

alter table compact只针对tiflash，tikv只能用脚本，给你提供个差不多的。
用shell只对oltp.sbtest8这个表(对应换成你的表名)做compact ,加-c write -d kv

mysql -uroot -pXXX -hxxx -PXXX information_schema -e “select region_id from tikv_region_status where db_name=‘oltp’ and table_name=‘sbtest8’”>region_list
cat region_list|while read line
do
tiup ctl:v5.1.0 tikv --host xxxx:20160 compact -r $line -d kv -c write --threads 1 --bottommost force
tiup ctl:v5.1.0 tikv --host xxx:20160 compact -r $line -d kv -c default --threads 1 --bottommost force
done

system · 2024 年8 月 2 日 09:22

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