小鎮最近做了個微信投票的活動，按照以往的慣性思維，小鎮就隨便寫寫代碼上線運行了。
當然在最初的一兩天裏面，小鎮的代碼出了點邏輯bug（程序猿的日常），自己不停的測試修改，三天後也進入平穩運行的階段。
寫的代碼無人問津是我們這種單位的家常便飯，所以很多的高併發性纔會產生的問題小鎮從來都是不考慮的。
然而。。。似乎大家對感動XX人物這種東東比較感興趣（小鎮做的項目叫感動南通人物投票評選）在一個星期的時間裏面參與的人越來越多，數據庫裏面的量也越來越大。（數據量大概在幾十萬）
哎，幾十萬的數據量也能卡住，這tm也有服務器的鍋，咱單位的服務器一臺上面跑了N多的數據庫，服務器的配置如下，大家看看就好別說話。（小鎮又不是沒有建立索引）
但是！就幾十萬的數據量也能卡，這一定就是我的鍋了，小鎮從來都是涉及到技術問題自動背鍋的人。服務器在昨晚9點左右出現了502（小鎮猜測是mysql卡住導致php進程滯留過多導致的），早上趕到單位一看，呵！mysql把cpu跑滿了！top下來下面一堆php進程。
So Sad!趕緊打開navicat for mysql查看一下究竟是哪條語句導致mysql性能如此之差，打開navicat中的服務器監控選項。截圖如下：
沒錯就是大家看到的那個長長的一句話。。。
在這裏，小鎮告訴大家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負載狀態！
好啦，這只是非常基礎的優化，但是小鎮也吸取了教訓，下次寫代碼要稍微考慮下高併發的情況了！~