不清楚需求的背景，猜测一下是想一次计算所有结果存下来以后直接查。如果是这种情况的话，反正只跑一次，就不用太在意计算的过程，反正 10 亿次的计算是少不了的，落库比较慢，至少比计算慢得多。基于这个前提，不如花时间想想后面的查询怎么优化

26 楼加 1，生产者：重试加 ack，broker：多副本，消费者：db 持久化位移之后提交位移，如果是写 es 的话只保证不丢，不保证不重复，如果消费者的任务是写 mysql 的话，和位移的持久化放到一个事务，可以保证恰好一次

我 965 比较空闲，从去年 7 月末开始刷，一直到今年年初，最近这两个月没怎么刷了，差不多到 300 题了吧，偶尔还打一打周赛。

inotify 是支持递归监听的

kafka 只有追加写的场景，肯定是顺序写，又不是 mysql，还有中间插入一条记录和修改某条记录的需求

4 楼+1，shell 写个脚本，用 inotify 递归监控总文件夹，文件创建后调用插入接口把路径传过去

我有个朋友最近想出他的笔记本，戴尔 Dell 灵越 14 燃轻薄本，19 年 7 月入。
i7-8565u，8g 内存。256 固态（后来自己又加了 8g 内存,1T 机械），价格在你的预算之内，他的微信 ZmFuZ19fX2tl （ base64 加密）

如果一定要非常精确的随机的话，可以 select count(*) from table，然后在应用层随机出来 30 个 id，把这 30 个 id 排序，从最小的 id@1 开始,select * from table limit id@1,1，从第二条开始 select * from table where id > (第一次取出来的 id) limit (id@2 - id@1),1

如果一定要非常精确的随机的话，可以 select count(*) from table，然后在应用层随机出来 30 个 id，把这 30 个 id 排序，从最小的 id@1 开始,select * from table limit id@1,1，从第二条开始 select * from table limit (id@2 - id@1),1

order by rand 全表扫描，还排序，如果对随机性要求不是很高的话，可以在取最大和最小 id，在应用层随机取 30 个 id，然后 select * from table where id > (随机出来的 id) limit 1，重复 30 次

函数的递归调用就是该函数在栈中有多个栈帧，程序只要模拟栈帧，不就可以将递归转化为迭代吗

我们也是这么做的，通过 redis pub/sub 实现分布式，订阅同一个 id，就可以实现类似聊天室的场景

我们做了个 web 端的聊天，就依赖模板消息提醒未读。。

@kikione 接口代码有问题，前面 select 的时候没加锁，后面 update 的时候结果错误是正常的，如果不想加锁的话，可以把 sql 写成 set product_price = product_price + num

建议把接口代码放上来

@extreme @carlclone
我认为你俩说的都没错，只是维度不一样.
1.一个事务删除一条记录的时候实际上是没有立即删除的，只是记录了 undolog，因为考虑到 mvcc 还有其他事务要读，这里的删除指的是内存里的删除。
2.删除的时候只标记为删除，后续复用的理解也是没问题的，这里的删除指的是从磁盘删除。

我们用的百度的 iocr，针对特定模板的，后来发现阿里照着百度抄了一个，抄也没抄全，难用的要死

极客时间，MySQL45 讲
+3，第一遍结课测验只考了 40 分，感觉好多东西没理解到位，正在过第二遍