修改某个用户的名字，这个用户有上万订单

> 有些软件甚至依赖好多个源

ppa 源的受害者

最简单的办法是给 repeated packed=true 看看
会改变序列化方式 java 和 c++ 都需要重新编译

首先你不该用 IN，没有一个数据库喜欢。

应该用 join on A.id = B.id

802.11 是 CSMA/CA，不存在两根天线一收一发，MIMO 也是要么全发射要么全接收

原理都差不多，但是没见任何 runtime 有现成的功能....

writer 一开始一个持有一个当前 index = 0

worker 把自己的 index - 1 用 CAS 推到 writer 上
> 失败就休眠，等 writer 唤醒自己
> 成功就返回成功，并唤醒 writer

writer 写完一个块就唤醒等在自己身上的 worker

> 然后按顺序非阻塞写到另外一个文件里.

接受者一个持有一个当前 index，发送者把自己的 index - 1 一个 CAS 到接受者上
失败就休眠，等发送者唤醒自己
成功就返回成功，并唤醒发送者

发送者写完一个块就唤醒等在自己身上的接受者

异步里很常见简单一个问题，除非你的程序是单纯的数据库 gui 的 api 都会有这个问题。

常见的思路是把线程分两组，一组用于异步事件轮询，一组用于阻塞任务。无论是 CPU 密集还是 IO 密集都可以这样搞，IO 密集阻塞如果去不掉的话就开一堆线程去做，CPU 密集就少开点线程。
比如
http://docs.libuv.org/en/v1.x/threadpool.html This thread pool is internally used to run all file system operations, as well as getaddrinfo and getnameinfo requests.
https://docs.rs/tokio-threadpool/0.1.18/tokio_threadpool/ Backup threads are intended only to support the blocking API.
asio 应该可以兼容手写的 thread poll

更 "工程" 的思路是实现抢占，比如 Go，只有一个 pool 然后一堆协程去抢，当然就会出现程序性能下限高上线极低。

Using filesort 看来 mysql 选择了对时间做外排序，复杂度 nlogn，实际上只选出几个元素有 logn 的算法的。或许 limit 1 优化器没利用上

> rows: 预估需要扫描的行数, 你的值在使用 create_time 索引时才 1131

最好情况扫 1 行，最坏情况扫 180w 行，mysql 的神奇优化器预估扫 1131 行就行了，但实际执行估计扫了十几万行

过滤到一个 sql 就结束，比扫全表稍微好一点点

order by xxx，xxx 上有索引所以 order by 不会触发排序

但是你有 filter, xxx 上的索引不够运行你的 filter，需要按主键（无论你用的是啥）取出你需要的字段做 filter。

xxx 上的索引扫到最后 limit 1 还得不到足够的结果就是最坏情况，扫全表

(0 or order_state = 2 or order_state = 4 or order_state = 5 ) and (order_property_bit & 128)=128 and channel_type = 2

这里堆经过 code gen 之后就是几个 if 而已，带一个和带一大对没什么区别

你自己按 time 排序并 limit 1 复杂度 log n, 这种事就别让给数据库干

索引用的是 create_time: 因为 order by create_time , 按 create_time 顺序扫出所有的 id 再对每个 id 用 auto_id 找 mchcode user_id sorder_state 等等字段并 limit 1，最好复杂度 1 最坏扫全表

索引用的是 mchcode: 因为 mchcode = '56789'，扫所有的 mchdoe= '56789' 的，取出 id 扫 auto_id 找 mchcode user_id sorder_state 等等字段， 按 time 排序 并 limit 1。最好复杂度=最坏复杂度，都是 mchcode = '56789' 的数量

优化器只能在最好复杂度和最坏复杂度之间蒙一个

@wangcansun 我一直在用，很香

产品经理：那是你的实现，我不管。我只知道 0.1 + 0.2 等于 0.3，不等于 0.3 就增加了使用难度，性能也不能下降

https://github.com/archlinuxcn/lilac/
https://build.opensuse.org/

定时访问一个上游，用某种方式解析出版本，用某种方式获得旧版本，再用某种方式比较版本。

然后用某种方式分析依赖关系，决定要重编译某些包，最后把它们编译好，打包。

再以某种方式构建好元数据供别人和本地版本做对比。

@huyinjie SN500 和东芝 RC 100 都是 nvme