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 区的比例, 增加晋升到老年代需要的存活次数

长连接只做登录认证好浪费

@HAPPYISOKA 这个我熟, 你们交互用啥, JSON? protobuf 还是其他

按照现在的行情, 买到就是亏到, 我个人会相信高盛的房地产分析, 国内房价还有下探空间; 既然你都怕 35 被裁员, 那就更不应该强行买房了, 总之先不急, 也别炒股了, 现金为王, 个人观点仅供参考

很有意思

@shockingFly 确实

@huangcjmail 底层只要是 B+树就可以这么分析, 思想是趋同的

@FlyingBackscratc 应该就是 sid_date_time 联合索引 sid 基数太少导致, 你使用 >=是无法利用组合索引的, sid 的基数太少, 需要扫描的页过多, 而且你是取所有数据, 还需要回表, 数据库引擎觉得全表扫描的成本比通过 sid + 索引下推 + 回表的成本低, 所以选择全表扫描

可能是 sid 作为索引基数太小了, 数据不够分散导致? 可以看下 optimize trace 分析

你们公司还招人不, 让我来吧, 这老哥的操作听起来就很迷, 很有必要做一下 codereview

数据补偿
recover