传感器数量基本固定，采集周期固定，要求低延迟。不知道中间串联消息队列并联缓存究竟是什么想法，造网站么...

市面上有现成的时序数据库：1 亿次写入 6 块钱，一小时 60 元，一天 1440 元。数据免费存一年。

你能想象你在和距离你 400 公里的人在网络上打游戏么？

那么是不是不同城市玩家水平会不一样？

功能少就 mustache，功能多就 jinja2

进程处于 zombie 状态

c++ 界的解决办法：动态链接

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

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

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 而已，带一个和带一大对没什么区别