【小镇的技术天梯】小镇的实战！mysql性能优化。

小镇最近做了个微信投票的活动，按照以往的惯性思维，小镇就随便写写代码上线运行了。

当然在最初的一两天里面，小镇的代码出了点逻辑bug（程序猿的日常），自己不停的测试修改，三天后也进入平稳运行的阶段。

写的代码无人问津是我们这种单位的家常便饭，所以很多的高并发性才会产生的问题小镇从来都是不考虑的。

然而。。。似乎大家对感动XX人物这种东东比较感兴趣（小镇做的项目叫感动南通人物投票评选）在一个星期的时间里面参与的人越来越多，数据库里面的量也越来越大。（数据量大概在几十万）

哎，几十万的数据量也能卡住，这tm也有服务器的锅，咱单位的服务器一台上面跑了N多的数据库，服务器的配置如下，大家看看就好别说话。（小镇又不是没有建立索引）

但是！就几十万的数据量也能卡，这一定就是我的锅了，小镇从来都是涉及到技术问题自动背锅的人。服务器在昨晚9点左右出现了502（小镇猜测是mysql卡住导致php进程滞留过多导致的），早上赶到单位一看，呵！mysql把cpu跑满了！top下来下面一堆php进程。

So Sad!赶紧打开navicat for mysql查看一下究竟是哪条语句导致mysql性能如此之差，打开navicat中的服务器监控选项。截图如下：

没错就是大家看到的那个长长的一句话。。。

 select * from `wx_toupiao_lapiao_count` lp left join wx_all_people ap on ap.openid=lp.selfopenid left join phpcms_content pc on pc.contentid=lp.uid left join wx_toupiao_phonenumber wp on wp.openid=lp.selfopenid order by lp.count DESC 

【哇哈哈哈哈，小镇自己也笑了，求DBA打死我。。恩，小镇这是快餐式写代码，谁知道有那么多人参与这个投票活动呢。。】

在这里，小镇告诉大家left join的这几张表的数据量都在10w朝上，就此也不难看出为啥这语句执行效率如此之慢，我在navicat里面运行了一下，要6秒多的时间。。。而且比较字段都建立了索引【DBA求不打脸。。。】

1、首先，小镇进行了表合并，将wx_all_people的表合并到wx_toupiao_lapiao_count中去了，反正是一一对应的，没有必要分表了，少了一个left join，速度快了2s左右。

2、然后小镇把星号改成了要取的字段，因为字段较多所以拖累了搜索速度。速度变成了0.8s左右，这么一看，这个才是拖累时间的大件。

3、因为小镇需要显示所有人的拉票投票的排名所以搜索所有的数据是在所难免的，但是小镇变了个弯子，每次加载50个，通过在sql语句后面加上limit限制，速度变成了0.02s，然后用户继续查看就发送ajax请求再请求50个，恩，这才正常！！

4、然后通过浏览器的f12查看加载速度再做进一步的优化，因为小镇写的代码的很多地方都用到了这句话，于是就将这个搜索结果做了缓存。ok了，加载速度快了好多好多，然后服务器也从卡死状态变为接近0负载状态！

好啦，这只是非常基础的优化，但是小镇也吸取了教训，下次写代码要稍微考虑下高并发的情况了！~