半年以来遇到的问题总结

‘About Question’

理论与实战

半年多没有更新blog，主要是工作太忙的原因，很多知识点都没办法总结，难得有时间能静下心来思考一下这半年以来遇到的知识点和错误

mysql异常

刚入职前几天我就发现，整个项目有很大的问题，代码只能算是能用，外包项目凌乱不堪，经常出问题，我遇到了有史以来最麻烦的问题，每天凌晨的时候cpu爆满到100%，这个问题持续了很久，最后是由外包出现解决，他们写的代码有极大的问题，但是很不幸的是，这个问题持续到现在，不确定负载均衡能否完全解决这儿问题，但是阿里的工程师建议使用这个方式

某天，外包的项目出现了我难以预料的问题，服务器504，我想了一下，不对，然后就重启了服务器，然后很尴尬的是，mysql重启以后无法再次启动了，然后就很奇怪

第一件事我想到了百度，结果我就遇到了很大的问题，同时磁盘又是满的状态，首先就是解决磁盘满的状态，我使用了人生第一次遇到的问题，运维的问题

du -h --max-depth=1
(这个命令和下面的命令作用是相同的)
du -sh * 
df -h
df -i（这个是后面用到的）
ll -h （这个命令并没有卵用）

说来坑爹，我再遇到问题的时候，第一时间百度，然后软连接的mysql，导致 mysql 启动异常，然后我永远记得那个时候，mysql启动不了要先去找启动日志，否则神仙难救

/www/wdlinux/mysql-5.5.54/data/iZ2ze95amp8ll8vsya794mZ.err

很碰巧的是，这个启动日志根本不好看，和正常的mysql完全不一样，因为整个项目是wdcp搭建的，我第一次明白了，理论其实有时候能快速帮你定位，但是不一定能帮你解决问题，最后是合作伙伴的 程序员 帮忙解决了这个问题

最后问题解决了，虽然我不是运维，但是当时360的一个程序员问我，你怎么维护服务器的时候，我才明白，不仅仅是主管要掌握维护的知识，小公司什么都要自己上手

随着时间的推进，我遇到了很大的问题，我发现凭借我一人的力量，这个项目根本没空驾驭，我修完一个问题，另一个问题都会接踵而至，我决定重构，我选择了 laravel 5.4作为我的新技术架构，主要原因是因为我喜欢这个框架，而且很大程度上，我认为这个框架设计的足够完善

但是很不幸的是，我一直在修问题，随之而来的，有很多奇奇怪怪的问题，比如用户为什么莫名其妙降级了，还有钱莫名其妙少了，我虽然一一解决了，但是a这个项目的问题，远远不仅仅只是解决，整个系统都有问题

运气不错的是，xin这个项目，合作伙伴会有相对应的维护，我必须要专注于修复项目问题，当时我修复急迫到什么程度呢，xin的后台项目我直接就在线上修改，因为我根本没有时间去搭建新的线下项目测试，这让我很不安

同时招聘的人员实在是水平不佳，没有独立的思考能力，外包的水平，一旦脱离了外包的项目，根本难以为继

有一个新的需求接踵而至，很郁闷的是，这个需求很急，我在4月底的时候收到了这个需求，5月1号就要完成

我开始了加班解决需求的功能，忘了说了，3月份，我就是不断的每天早上早起，解决cpu爆满的问题，我再mysql上面做了很多的努力

show processlist
kill xxx
这两个命令是我经常使用的命令
就是为了保证cpu能空出一点点的资源

后面，被外包蒙骗，说是要迁移到rds上，我第一次相信了他们，后来才直接，rds根本不是问题的关键，而是环信的圈子，才是问题的关键，他们说环信被人攻击了….

好吧，他们加密了，解决了，我当时的感觉就是我驾驶着一艘破船，随时都有可能会坏的破船

我完成了51活动的需求，很不容易，但是最终还是完成了，我把整个精力放到了重构上，我搭建起了laravel，准备把整个项目重构到laravel上面去

很不幸的是，旧版的活跃度计算奇慢无比，因为需求增加了新的内容，然后我又要准备着手重构活跃度脚本

我重构的时候，才明白实现需求，当时有人问我，如果要实现联合查询怎么办，我当时想也不想，直接说，先用 php 查出来，再循环解决，然后我就用了这个方式，很不幸的是，坏到吓人，整个系统脚本几乎等同于坏掉,然而我的运气不错，我找到了一个当年的合作伙伴

select id from user where pid in (select id from user where pid in (select id from user where pid = 123))（典型的效率极差，200w以内数据没问题的查询语句）（当然，你查出来以后去查，效率更差）

优化方式

隐式写法
select t1.id from user t1, user t2 , user t3 where t2.id = t3.pid and t2.id = t1.pid and t3.pid = 123

显式写法
   SELECT 
        *
    FROM
        lc_user
    WHERE
        id = 1313108
    UNION
    SELECT
        t2.* 
    FROM
        lc_user t1
        INNER JOIN lc_user t2 ON t1.id = t2.parent_id 
    WHERE
        t1.id = 1313108
    UNION
    SELECT
        t3.* 
    FROM
        lc_user t1
        INNER JOIN lc_user t2 ON t1.id = t2.parent_id
        INNER JOIN lc_user t3 ON t2.id = t3.parent_id 
    WHERE
        t1.id = 1313108
    UNION
    SELECT
        t4.* 
    FROM
        lc_user t1
        INNER JOIN lc_user t2 ON t1.id = t2.parent_id
        INNER JOIN lc_user t3 ON t2.id = t3.parent_id
        INNER JOIN lc_user t4 ON t3.id = t4.parent_id 
    WHERE
        t1.id = 1313108

我突然明白了，上学的时候，老师说的左右连接的真正用法，有时候逻辑理解的时候终究是，纸上谈兵终觉浅，一用才知道，什么叫做难

中途我遇上了很多的问题，我的压力很大，但是我还是扛下来了，我的合作伙伴帮助我解决了我一直无法找到原因的，本地测试搭建的问题，这个问题很重要，简直就是久旱逢甘霖，之后的开发显得顺风顺水了

当我面临设计laravel的基础的时候，我才明白，当你从头到尾想设计一个东西的时候，难度还是非常大的，因为你要考虑到很多的内容和东西，不仅仅只是单个，我的同学曾经设计了一个验证的方式，幸好他设计过了，我把他的思路搬了过来，用laravel的中间件实现了

解决了最重要的基础架子问题，我的伙伴正好又把svn搭建出来了，这很棒，我们开始了非常良好的开发良性循环

随着 工具 的不断完善，我们开始了开发支付，微信登录的功能