udf 呗

你这个是四个表的 join ，500 万的四次方也很大了。写成子查询看看呢？做个 archived 和 userid 的联合 btree 索引试一试？

直接 json 里提取一下文本就行了吧，很简单的

白嫖？

btc

base 哪里，第一次出去就好好炒菜吧，大炒 3 天

请问是如何接到项目的

@haython 大大提高并发当然是相对于可窜行化级别来说的。

2.第二个方面，MySQL 中，A 事务在执行过程中，要多次使用某条记录，我怕它两次访问查出来结果不一样，反正都是同一条记录，我咋不只查一次，一直就用第一次查出来的。
--------
比如飞机选座，一个 A 用户先查询座位图，花 10 分钟做决定，选了一个位置 X ，提交。在这 10 分钟内，B 用户查询座位图，选 X ，提交。这个时候如果 A 只查一次然后提交（也就是不可重复读），那 A 和 B 会选同一个座位（冲突）。但实际上在可重复读级别下会再读一次，然后 A 事务提交失败的。

直播

可重读级别好处是可以大大提高数据库的并发。读的数据是假（旧）的概率不高，而且即使是假（旧）的，在一些应用下也不会对应用照成影响，在这样的应用下可重读的作用是巨大的。比如你 12306 定火车票的时候经常查询的时候余票有 1 张，但是付款的时候显示没有余票了。这个查询余票的功能就是可重复读，读到了假（旧）的数据也没事。最后下单的时候的隔离级别高就行。查询余票的隔离级别低可以让更多人同时去查询。

能大概讲讲怎么上线的嘛？前端后端，服务器，还有网址都咋弄的

或者找个 A 轮 B 轮的 startup ，乘着年轻去赌一把

虽然楼主说不想来美国，不过作为过来人我还是建议读个美硕进美国大厂。top2 cs 进美国大厂还是有 buff 加成的。然后就可以 WLB 了。

这特么，海外身份还没有社保没有 401K 没有保险，3K USDT ，现在人这么便宜了吗

回美国村里躺平

参与

数据库不可能为了这一个单一需求做定制化的。应该不会是定时刷新。只记录流水也不行的，每次转账都要读一次数据看余额是否够 扣款的。

总结说来，正常银行不会让你一秒转百万笔汇款的。