索引用的是 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

gc 扫描

因为你的 str1 只有 a 一个值，查询转化成 where str1='a' and str2 > 'b'，完全命中索引

我贴一个神奇的芯片，DisplayLink 公司的 DL-6000

真正的 USB 3.0 协议，一个 Type A 就可以工作，使用 Type C 时还可以给设备充电，不给设备供电时无需外接电源。

可以输出 1 个 5k 60 或者 2 个 4k 60 或者 4 个 1080p 60，外加 1 个 Gbe 和 2 个 USB 3.0 再加一个 5.1 声卡。

产品的价格从 100 美元到 200 美元都有

雷电 3 host 只有 3.3v 供电能力和 usb 1.1 5v 500ma 差不多，带 1 个 usb 都吃力

变量转 interface 时会隐式引入指针
函数调用时变成指针会造成变量逃逸，分配到堆上
栈上的变量只能被栈上的指针指向

这不是说 go 的逃逸分析很烂，是在说 go 羸弱的类型系统没法支撑 void* 这样的零开销抽象

go 完全无视了现代 pl 界的研究成果，一群写 c 的造了一个自己认为比 c 好的语言。
接触过现代语言的自然会感到不舒服。

异步流式 builder api 除了写法发生变化，有时候增加或者减轻了心智负担外还有个优点。
这些 api 都增强了语义，编译器能更好的理解你想干嘛，优化力度能开的很大。

比如 steaming api，业务要先 zap 再算加法，再 zap 再算除法。传统 api 要遍历好几遍，streaming 遍历一遍就算出来，对 cpu 缓存友好几倍。

反观 go 语言，在可预见的未来会比 java 还慢

说 Texpad 好用的欢迎体验 Kile，Linux 下的软件，没有竞品。

@ipwx @lvybupt

google 的 api 就烂的很，给你一堆从 protobuf 上生成出来的东西，还不如直接去读那一堆 proto 文件。

就目前观察来看 TB_HEADER 是个 gpio
短接 = 雷电 3 启用
断开 = 雷电 3 关闭

啥时候 LinkedList 能不支持随机访问

比较好玩的是现在用了 cnvio 的笔记本都会神奇的消失一根 pcie, 雷电接口+nvme+显卡+ usb 的数量依然不对, 我怀疑 cnvio 的传输层还是用了一根 pci-e 和 usb, 和以前没什么区别

https://www.amazon.com/Intel-Wireless-Network-9560AC-9560NGW-Gigabit/dp/B07V4X4VZH 9560 $20.50
https://www.amazon.com/Intel-Wireless-Ac-9260-2230-Gigabit/dp/B079QH5KW1 9260 $13.55

9260 和 9560 是同一代的网卡，9560 是 9 代网卡 + cnvio，9260 是 9 代网卡兼容以前的 pci-e+usb
不存在新旧之分

我认为是市场部门脑残，cnvio 是新技术，只有高端新主板才支持，这部分人会买更贵的网卡，cnvio 网卡应该卖的更贵，和雷电 3 一样

下次主流框架牵着大家升级的时候这个主流框架大概率不会是 java 了