【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
表结构
查询语句
执行计划
使用到了索引,手工执行也很快,为啥会是慢查,dashboard的cop消耗这么长时间 ,请教从哪个方向分析?
【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
表结构
查询语句
执行计划
使用到了索引,手工执行也很快,为啥会是慢查,dashboard的cop消耗这么长时间 ,请教从哪个方向分析?
建议看看accountid的数据分布,有多少条,多大
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 41881722
Avg_row_length: 104
Data_length: 4355699088
Max_data_length: 0
Index_length: 670107552
Data_free: 0
Auto_increment: 42113927
Create_time: 2023-07-20 02:50:58
Update_time: NULL
Check_time: NULL
Collation: utf8mb4_unicode_ci
Checksum:
Create_options:
是不是order by引起的?
dashboard看也就0.5秒,也不太慢吧
看看coprocessor读取那一页的内容
结果只有一行吗
Coprocessor等待耗时高而执行耗时低,应该是整个系统的tikv Coprocessor 压力比较大吧,Coprocessor 线程忙碌导致等待
account_id返回数据并不多
量大不大,有时候内存没命中,扫盘有可能有长尾的。
有可能tikv负载高,看看tikv cpu和io总的情况
手工执行很快
1 row in set (0.00 sec)
执行计划
time:524.5µs, loops:2, cop_task: {num: 1, max: 482.9µs, proc_keys: 2, rpc_num: 1, rpc_time: 465.9µs, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 2, total_process_keys_size: 110, total_keys: 3, get_snapshot_time: 10.4µs, rocksdb: {key_skipped_count: 2, block: {cache_hit_count: 11}}}
time:934.3µs, loops:2, cop_task: {num: 2, max: 442.1µs, min: 420µs, avg: 431µs, p95: 442.1µs, max_proc_keys: 1, p95_proc_keys: 1, rpc_num: 2, rpc_time: 841.4µs, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15}, tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:2, tasks:2}, scan_detail: {total_process_keys: 2, total_process_keys_size: 309, total_keys: 2, get_snapshot_time: 17.8µs, rocksdb: {block: {cache_hit_count: 20}}}
grafana哪个指标可以验证这一点
监控 tikv 有命中率,但是这玩意又不能实锤你这个 SQL 是这个影响了。
把dashboard那条慢sql的执行计划贴出来
最重要的信息在右边