LiaoMatt

select * from info where a > 1 and b = 200
select * from info where a >= 1 and b = 20
这两句 SQL 是用不到联合索引的 b 的, 因为联合索引是先按照 a 从小往大排序, 再基于 a 的顺序从小往大排 b, 这就意味着, 如果 a 不是等值, 那么 b 的顺序就没有办法保证, 只能一行一行扫描

@Zaden 有联合索引吗, 还得看看数据库的配置

@Huelse eSim 更安全, 一般大家都不会设置 sim 卡密, 如果手机丢了, 捡到手机的人完全可以把卡拿出来, 然后去登录一些只做了验证码校验的 app 然后操作, 但是 esim 不会有这种情况

如果是直接内存分配失败的 OOM, 你可以关注下 dmsg, 在业务日志上是没有体现的, 如果用 systemd 托管服务可能还可以看到有用的信息

进程假死了, 没有任何响应, 这就就是 OOM 的表现, 把服务器配置贴出来

包装模式, 每次包装减少对应的金额?

@skyemin 只有大对象才会有这个情况, 而且从参数来看没有设置 PretenureSizeThreshold 阈值

花里胡哨的 JVM 参数配置太多了, 管理的内存这么大, 如果是 JDK8 直接用 G1GC, 然后其他参数不用配置, 应该情况也会好很多

1. NewRatio 和 Xmn 同时设置只会生效一个, 优先 Xmn;
2. Suvivor 占用比例是不是可以更小一些, 比如 20:1:1, 目前一个 suvivor 有 500M, 两个就有 1GB, 对象实例很容易就能晋级到老年代(个人觉得), 然后每次 FullGC 又把这些提升到老年代的实例释放,能腾出 430MB 让程序勉强走下去; 应对方法, 降低 suvivor 区的比例, 增加晋升到老年代需要的存活次数