C 的难点在于各种奇技淫巧黑科技的指针操作，写 C 的过程中脑子里就要映射出一个内存模型。

A 查询走的全表却比 B 查询快，原因是因为 A 用到了覆盖索引（即索引是 money 而查询字段也是 money，那么数据就可以直接在索引上获得了。B 查询用的索引是 cid 而字段还是 money，在索引到行 id 后还需要根据 id 查找数据）。
这里的要优化 B 的话可以按照这个思路，建一个(cid, money)的索引，这样 B 也就能用到覆盖索引了。
当然你这个表全是索引了...索引不是这样建的，这样索引会比数据还大，要根据实际查询的情况而定。

我觉得钉钉除了已读功能不爽外其他都没啥。打卡基本只是个形式，每周只需要写周报，下班和周末时间除非是紧急的事情才会钉人，一般情况下不会占用大家的私人时间。

马老 C ？

@asaxing 40%套牢的路过

应该是你的数据里没有 A 开头的，我记得要是没有命中索引的数据，执行计划是显示全表的。

只是日志收集的话，那就是 logstash 啊

字符图表用的什么库？

@q397064399 学习了！

页端的话要么追踪调试 js 摸清解密方式，要么用浏览器抓取。
APP 的话要么反编译获取解密函数，要么用模拟点击的形式实现。

@qiayue 我登陆也有啊

@zynlp 这个不符合内存泄露的定义，暴增的 list 对象始终是有被引用的，这放任何一种语言不断地填一个数组都会把内存撑爆啊。

扫一眼下来只有我一个是有降过的吗 = =
2015 年毕业北京 13.5k
2016 年涨 10%：15k
2017 年跳槽到广州：14k = =，且年终还少了俩月
2018 年 16k
感觉好艰难

实际上如果拿 uuid 来做主键的话，性能会更差。
innodb 内部数据会按照主键来排序，如果是自增主键，插入数据时只需要不断在磁盘块后面追加即可，但如果是 uuid 做主键，每次插入会把该条数据插入到对应的排序位置中去，往往会造成大量的数据移动，造成磁盘块分裂，出现大量磁盘碎片。

用 git rebase 当前分支，可以将多个提交合并成一个提交，这样就不会有大量的「小提交」了。

@qichengzx 通常只有分布式系统（如分布式数据库）才需要用到全局唯一 id，如果是初期的项目，往往根本不需要用分布式系统，根本不存在你这个系统的使用场景啊。

权力的游戏。只看了 20%

list 在 C 实现中的数据结构是一个 PyObject*类型的数组，不具备链表的特性。
楼主应使用 deque，是一个双向链表的实现。