结果咋样，测试了吗
还没改参数测试，我们先在业务上把这个查询给优化掉了，通过跑批的方式去生成结果表再直接查结果表的数据
我晚上用命令跑下看下效果
刚刚测试过了，在be.conf开启disable_storage_page_cache=false; 后测了下，有一定效果，但是并发100左右还是很耗资源，由于这个数据的时效性要求不是很高，让业务先离线跑批生成结果表，然后再去查数据了。感谢大佬的支持。
对于这个表创建个索引会好很多，ASIN不是Key 吧
如果不是的话，asin 这上面建个BloomFilterIndex 试试
不是key的，我试一下建 BloomFilterIndex 再看下
创建bloomfilter index 后有效果吗。
是有效果的，看profile有命中 bloomfilter index
在单并发情况下比之前快一倍左右
50个并发左右查询也能在1s左右，也比之前快
但是开到100个并发查询的时间跟之前的是差不多了,在 2.4 - 2.6s左右
大佬有空可以帮忙再看下profile
1并发profile.txt (24.1 KB)
100并发profile.txt (24.0 KB)
看100 并发的profile还是pending的时间变长了，请问这部分是不是 cpu不够了，然后一直在等待照成的，这个表现在只搞了一个副本，搞到3个副本会不会更好一些呢？
CPU打满了吗？
应该可以更快，这个SQL应该是可以命中前缀索引的，不应该这么慢，需要看下是哪里的问题。这个表有多大？
你给我几个数据片断，我模拟下？
12个Be × 32C/128G？
Profile关了测试吧？
CPU在60 - 70% 左右
表的数据有 466532074
是12个BE 32C 128G的配置的
测试的时候profile关闭了
相关的数据片段在下面这个文件里面，请大佬查收:
data.txt (8.6 KB)
感觉不太合理，我先自己测试下吧。
压测的时候，可以截一个 perf top的图吗？
在BE的机器上执行 sudo perf top
可以的，我晚点发一下出来