聊天记录里找了一张截图，不是很全
走tiflash的话，tiflash支持的sql并发能力查，看看当时负载是不是很高
当时cpu 、内存、io都还好
上面有15点15左右的性能监控图，就是这个点的时候query count比平时多了一点
https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze#tablefullscan-tiflash
tiflash_scan:{
dtfile:{
total_scanned_packs:3490,
total_skipped_packs:10830,
total_scanned_rows:28492955,
total_skipped_rows:88357511,
total_rs_index_load_time: 0ms,
total_read_time: 1373ms},
total_create_snapshot_time: 0ms,
total_local_region_num: 0,
total_remote_region_num: 44}
total_scanned_rows：DTFile 内累计读取的行数；若存在 MVCC 带来的多版本更新或删除，则每个版本独立计数。
主要是扫描的时间就长。
然后扫描的描述里面。total_scanned_rows比执行计划里面的estrows大一个数量级。
gc的设置时间是多少？
客户端工具执行都是正常的，就在业务接口调用的时候搜，会出现慢的情况
可以根据这个SQL的Digest搜索下是否是出现了多个执行计划，如果是，看下快的执行计划和慢执行计划的区别是怎样的；如果不是，则要分析下，慢在哪一步。
从第一步扫表数据开始，就慢了
如果耗时差异主要在第一步扫描，那得分析下当时的数据库负载了，是不是有比较多的慢SQL在执行
这个sql强制走tiflash的，就上图15：15左右，这个点两台tiflash服务器的负载不高
你在本机设置
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=1;
看下快不快，如果快的话，强制都走mpp模式试下
比较快的
客户端执行都很快，就是应用程序调用的时候，会偶尔出现慢的情况
你看下本地的执行计划，是cop【tiflash】还是mpp【tiflash】
本地MPP，慢的时候是cop
那这个程序都调用了哪些东西呢？让开发看下调用这个SQL的整体脚本是啥呗
这个sql的接口里，就只有这么一个sql
应该是执行计划变了得缘故，mpp[tiflash]变成了cop[tiflash]，估计是自动收集得统计信息问题
1 个赞
那你直接全局设置成强制mpp试试
set global tidb_allow_mpp=1;
set global tidb_enforce_mpp=1;