yufpga

每次合并之前，pull master 分支并不是必须的。因为你最后 push master 的时候，如果远程 master 分支有未 pull 的内容，会要求你先 pull master，否则你无法将本地的修改 push 到 master 上去. 另外还可以参考 git-flow 的流程.

首先一点，要知道一台 4 核 4 线程的计算机, cpu 最大只能并行处理 4 个任务, 也就是说最多 4 个线程能同时跑在 cpu 上。假如一个程序，创建了 100 个线程, 那么同一时间只有 4 个线程能跑；如果我创建的是 4 个线程和 100 个协程, 虽然我也只能同时跑 4 个线程, 但是考虑到协程上下文切换以及协程本身所消耗的资源要比线程小很多, 你说哪个划算. 而且不同语言的协程方式实现不一样，并不一定需要和你说的一样需要创建一个线程来专门调度这些协程. 比如有的是栈协程(python 等), 还有 go 语言的 goroutine 调度也并不是专门给协程调度创建一个新的系统线程，而是通过 goroutine 绑定到系统线程(这个系统线程可并不是专门为协程调度服务的)

@justin2018 说实话，我也不知道

ucloud:

https://www.ucloud.cn/site/global.html?ytag=%E5%87%BA%E6%B5%B7_sifou_ad#xianggang

方法对可以, 方法不对, 再努力也白瞎

asyncinotify

https://pypi.org/project/asyncinotify/
https://asyncinotify.readthedocs.io/en/latest/

a.time 加了索引也没用，innodb 非主键的索引是非聚簇索引, 不支持范围查询的，用这种>, <的应该是不会走索引的, 还是得全表扫描，select a.x, a.bid from A a where a.time >= xxx and b.time <= xxx limit 0, 100 这条 sql 应该是全表扫描的，explain 一下看看就知道了。就单表来说，两张表都不算小，分开写比较合理。之所以原查询慢，是因为两张表的数据 join 在一起太多了，而 innodb 的 buffer pool 远远不够，频繁读取磁盘数据到 buffer pool 这个过程很慢。

计算机中的空间，时间和物理中的空间，时间不是一个概念。计算机中的空间指的是内存(物理存储介质)的空间，时间指的是 cpu 的时间, 是一个非常具体且可以衡量的东西。物理上的空间和时间,我不是搞物理的,解释不了。