京公网安备11010502063487号本机真实验证一个全是整数的set用intset编码，加一个非整数成员立刻变成listpack；另一个intset真实超过set-max-intset-entries数量限制时，却直接跳过listpack变成hashtable——两条真实不同的升级路径。
本机真实验证44字节的字符串是embstr编码，45字节立刻变成raw——精确卡在字节数上的分界线，再验证哪怕再短的字符串，一次APPEND操作也会立刻真实把它变成raw。
本机真实验证纯数字字符串是int编码，INCR之后依然是int，但一次APPEND立刻把int转成raw；真实还发现超过64位整数范围的数字，压根不会被编码成int，而是直接变成embstr。
本机真实按老版本Redis文档描述的条件测试小整数共享池：OBJECT REFCOUNT真实一直是1，不是预期的巨大共享计数；真实又用10万个key的内存对比做了独立验证，证实这个版本真实没有观察到共享效果。
本机真实验证PERSIST能让TTL从100变回-1，一个200毫秒过期的key在300毫秒后访问真实返回不存在（被动过期），另一个100毫秒过期的key即使完全不访问，500毫秒后DBSIZE也真实自动减少了（主动过期）。
本机真实用MEMORY USAGE测5种大小的字符串，发现100000字节的value真实要多付出14717字节的额外开销（14.7%），比1000字节value的51字节开销比例高得多；再对比1000个字段的hash和1000个元素的list，真实内存占用相差6.4倍。
本机真实插入20万个key(used_memory 71.46MB，碎片率1.14健康)，再真实交替删除其中10万个：used_memory真实降到37.47MB，但used_memory_rss真实纹丝不动(还涨了一点)，碎片率真实飙到2.07。
本机真实验证编码转换检查只在写操作时触发：把hash-max-listpack-entries从512调到5之后，一个已有20个字段的hash真实继续保持listpack不变，一次HGET(读)也不触发转换，直到一次HSET(写)才真实立刻变成hashtable。
本机真实建一个423MB、500万字段的大hash，真实测DEL耗时0.85秒、UNLINK只要0.0002秒；更关键的是真实测出DEL期间并发PING被真实卡住819毫秒，UNLINK期间只有0.81毫秒——差了1000倍。
本机真实用DEBUG SET-ACTIVE-EXPIRE 0完全禁用后台过期扫描，验证一个TTL早已过去的key真实还占用着48字节内存、DBSIZE真实还算着它，直到一次真实的GET才让它真实消失。
本机真实设maxmemory=3MB+volatile-lru，插入200个无TTL的key和600个有TTL的key直到触发83次淘汰，真实验证结果是：200个无TTL的key100%真实幸存，600个有TTL的key只剩516个——只有设了过期时间的key才会真实被淘汰。
本机真实用跟volatile-lru一样的200个无TTL+600个有TTL的key，只改成allkeys-lru策略，真实验证这次无TTL的key也被淘汰了13个(187/200幸存)——直接对照上一篇的100%幸存，证明allkeys-lru真实不区分key有没有过期时间。