@SJH0402 你要是能直接把查询优化好, 有人会不听你的方案吗?

1. 把关键词列表放到一个 list, 去重排序, 并且把原先的关键词列表替换为这里的 rank, 关键词列表变成 list<list<rank>> 即把 string 离散化.

2. 把上面的 list<string> 变成 ac 自动机, 在文本中搜索. 得到一个 list<int>

3. 在 list<list<rank>>里搜索有哪几个 list<rank>是 list<int>的子序列, 在这里面抄一个最快的算法 https://leetcode.cn/problems/number-of-matching-subsequences/description/

个人建议别熔断, 做这种事情就是纯背锅的.

n = 3000000
id = [i for i in range(n)]
原价 = [random.random() * 99999999 for _ in range(n)]
厂家折扣 = [random.random() * 1000 for _ in range(n)]
卖家折扣 = [random.random() * 1000 for _ in range(n)]
买家折扣 = [random.random() * 1000 for _ in range(n)]
汇率 = [random.random() * 10 for _ in range(n)]

table = list(zip(id, 原价, 厂家折扣, 卖家折扣, 买家折扣, 汇率))


def sort_by(row):
id, 原价, 厂家折扣, 卖家折扣, 买家折扣, 汇率 = row
return 原价 - 厂家折扣 - 卖家折扣 - 买家折扣 * 汇率


import time

start = time.time()
table.sort(key=sort_by)

print(time.time() - start) # 1.0334241390228271


300w 行用 python 全部排序也才 1 秒, 数据库里 c/c++的排序怎么可能要 10 秒呢?
况且 limit n 的情况下只需要 O(n)的排序算法. python 里的还是 O(nlogn)的.

你该不会是把数据全拉到本地再计算的吧.

怎么上来就复读程序员思维? 我看 op 也没说要用技术来解决吧?

core dump 下来, 到本地的 goland 里看

Settings -> Build, Exections, Deployment -> Deployment -> optional -> Delete remote files when local are deleted;

要快应该得搞点 simd 吧(readme 里也提到了), 这个代码里好像也没有.

这个 sql 什么意思, 感觉逻辑很奇怪, 一般来说 open_time 应该小于 close_time 吧


总之想个办法, 把其中一个时间改成 between 一个较小的时间段, 性能应该就会好不少.

现在是 2 个大 set 取交集, 肯定很慢.

你这个 c++问 ub 有什么区别?

具体的代码是怎么样的?
inverted logic 看起来像是让你把
if ( not flag) { A } else { B } 改成
if (flag) { B } else { A }

是的, 对于降低 p99 有明显的效果

我觉得也就 c++ 要远程开发, 笔记本实在编译不动. 其他语言都无所谓吧.

其实是认为 resp, err 这样的写法有 4 种情况
1. nil, err
2. nil, nil
3. resp, err
4. resp, nil

而实际上只有 1 和 4 是比较标准的格式, 没有在语言层面上禁止 2,3 这 2 种写法, 虽然我觉得根本无所谓.

红黑树查询的时候不是和普通的二叉树是一样的吗?
这个例子来说, 先 lowerbound 找到 3 , 然后调 next 10 次

写 go 的应该会背 sync map 的八股文吧,
为什么有并发的情况下不抄这个的实现,
而要是每次都 Unmarshal json?

用这个数据结构为基础, 我猜应该可以做到差不多的性能.
https://github.com/BurntSushi/fst

喷点只有
1. 不规范
2. 逗号不在 url 转义的表里, 一定要这样搞用个分号, 保证不切错(包括后端的存储)

硬要说性能, 我猜这样 split 性能会比解 json 更好.