在一次查询和同时提交50个查询的时候出现耗时大幅增加的问题，我对比发现 profile 里面有这几个指标有问题，请问这几个指标是什么原因引起的
一个是 PeakDriverQueueSize ，一个是 PreconditionBlockTime
set global pipeline_dop=1; 再压测下试试。
巨佬，这个pipeline_dop=1 会影响到 PreconditionBlockTime 吗
压测的时候，把enable_profile关掉，
压测的时候，瓶颈是FE还是BE？如果是BE的话，获取一个perf top
谈不上压测吧，我只是试一下同时提交多个查询的情况，看上去是 pipeline 排队耗时太长了，这是BE的问题吧，不知道怎么解决
5个查询同时提交，都比单个查询慢很多
提供的信息太少了，不好判断。最好关闭Profile，然后获取下perf top，或是发个完整的profile.
来看看佬
6f171c94-0f5f-11ef-bd45-4ad2f670bd91-profile_100并发.txt (64.7 KB) c3741944-0f5f-11ef-bd45-4ad2f670bd91-profile_并发50.txt (64.8 KB) e91a4f66-0f5f-11ef-bd45-4ad2f670bd91-profile_并发1.txt (64.8 KB)
我们用的阿里云，profile 下来就是 json
set global pipeline_dop=1; 然后 set global enable_profile=false; 再测试。
"Collect Profile Time": "112ms", "QueryPeakScheduleTime": "46.669ms",
只保存1000个
谢谢大佬，有一个疑问，那我关了再开？开之后的1000个有保存，还是？
有表可以查具体那些SQL 被缓存？或者有什么方法把这1000个清除重新采集
全局关了，单独对某个SQL开启就行
这种方式在查单条的SQL是有用，
但是会遇到这种情况show full processlist 看time时间很长（包括audit.log记录时间也很长，但整体负载不高）
但是手动执行却很快，这种就没办法对比手动执行与程序跑的时候profile是否有差异
高版本有长尾自动上报profile，可以找下文档