昆仑的山头

如果你在你的mysql里看到了这个数，一定稍微停下来想想
两周前写的同步联系人的方法，定时执行，半小时一次，已有的更新，没有的插入新数据

1
2
3
4
5
6
7
8
9
10
11
12
13

if(count($contacts) > 0){
    foreach($contacts as $co){
        $c = Contacts::where('uin', $co['Uin'])->first();
        if(empty($c)){
            $c = new Contacts();
            $c->uin = $co['Uin'];
        }
        $c->nick_name    = $co['NickName'];
        $c->user_name    = $co['UserName'];
        $c->last_fri_uid = $friUin;
        $c->save();
    }
}

很简单地逻辑吧~~
因为是demo项目，写完以后正常跑着，就没怎么细看
今天看Contacts库里面。。。。。。x，已经十几万条数据了
可以实际上只有几十个联系人，稍微细看，NickName全是重的
当时就对着这段程序找bug，加日志，但是，真没发现问题

在仔细看错误的数据，uin字段都是2147483647。。。好像猜到问题了。
于是百度mysql int字段的长度，恩，2147483647正式int的最大长度，如果给更大的数，存进去的还是这个~~与你建表是给这个字段的length无关
而这里的uin，正是这样一个长度不定的字段
好吧，这坑掉的值
字段改成bigint，或者varchar都ok，考虑的uin是外部传来的数据，还是varchar靠谱些
然后，“date -r 2147483647”，返回“2038年 1月19日 星期二 11时14分07秒 CST”，呵呵，这就是所谓的2038年问题
以前时间也都是用int保存的，以后再用到的时候，要不要都改成bigint字段？~~~思考中