@wensonsmith 这个很对，最关键的还是要多动手

还是很佩服坚持写 blog 的人，思想有沉淀，成长有轨迹。

真是个人才

people_check 是一个分区表？ 分区的方式是什么样子的？ 分区表不带分区字段，查询肯定会非常慢了。

people 表只有一条记录么？ 如果是的话，或者记录条数很少的话，就没必要做 join 了，可以考虑用 in 替换一下

@waibunleung 当时还在学校，勉强交付，也就没有后续了。

之前也遇到过类似的情况，当时对项目没当回事，就随便搞了一版，带着练手的心态搞项目，最后就很尴尬

区分工作和事业，当前的工作，只是事业的一部分

从你发的截图看，年轻代增长很快，且每次 ygc 后都能回收大部分数据，但对应的老年代的空间上涨并不是特别快。这说明年轻代的这些对象基本都是临时对象，达不到常驻内存的条件，你们的 ygc 的耗时比较高。这种情况很可能是由于使用了类似本地缓存的模块，使用了 LRU 相关的策略，缓存的命中率并不高，新产生的年轻代的对象不停的往缓存中扔，缓存快速 LRU 淘汰，从而产生了年轻代被年老代引用的情况。


cardtable 内部只是存储了一块内存是否引用年轻代的标识，实际还是需要针对这块内存进行引用计数，判断年轻代的对象是否可回收

ygc 耗时高有很多种原因，常见的是年轻代的对象被年老代引用，每次统计是不是可以在 ygc 阶段回收的时候，都需要去年老代看引用的根对象是不是引用计数为 0，这段时间可能会导致耗时比较高。