直接报警处理，现在诈骗查的很紧，感觉像是诈骗

曾经的减肥计划
1.戒掉米饭，换成粗粮，如荞麦面等，吃菜和蛋白质类的食物
2.每天坚持游泳 1000 米
3.坚持就可以了

@liweiwen 选择回女朋友家那边衢州玩两三天

同准备去江西景德镇，被酒店价格劝退

吃羊杂碎，每年回去最想吃的东西

入手了 007 试驾新款 model3 的时候感觉舒适性可能有点差 我还是希望兼容下舒适性 su7 没有 800v 也是个小问题

@LHRUN 我是在工作中遇到打球的朋友，其实就是公司同事，但是不是同一个大部门，每天吃饭时间去打打球很开心

可以尝试多多融入一些 游戏\篮球\户外等圈子，有朋友一起玩就不会三分钟热度了，我一个人玩游戏也玩不下去，有朋友一起玩比较开心

995.5 每天都打球

不对 offer 评价，Kook 产品还是可以的，用的挺喜欢

@themostlazyman 插入的版本号是用户的总版本号，比如用户插入了配置 A ，此时 version=1 ，用户再次插入配置 B ，此时 version=2 ，版本号记录了用户的所有操作记录

@zhengwenk 同一个用户账号在多端同时操作这个业务的配置信息

@shinelamla
@markgor 这是一个好方法 我会尝试从此方面入手，因为有需求是根据某个版本号，返回全部的 config_id ，在查询时我要先将 userid,business_type 排序，获取对应的入参版本号的记录，获取时间戳，返回该小于该时间戳的所有 config_id

@themostlazyman 上锁可以解决所有并发问题，但是现在可能会对性能有影响，我一开始的方案也是上锁

@justfindu
@shinelamla
每个用户的不同 business_type 都是重新计算版本号的，不用业务有不同版本号，自增操作要通过触发器来更新，触发器现在公司尽量不能使用

@shinelamla 在高并发下两条 insert 语句同时获得了上一个最新的版本号，这样会导致版本号丢失一次自增

@shinelamla 在高并发插入的时候怎么处理比较好呢

@themostlazyman 更新的时候是没问题的 可以用 CAS 来控制，但是我现在在 Insert 的时候不知道要怎么控制

@coderxy 数据库里的每个用户和业务类型 都有一份自己的总版本号 并不是这个表的 total_version 是一个自增的