余歆昨晚连夜上线了榜单功能，上线后简单测试了下，感觉没啥问题就休息了。
没想到一早上醒来，就看到好几个朋友给发消息问为啥社区访问不了了。
还好今早比往常早醒了半个小时，抓紧时间排查。
输入社区网址，访问一直处于等待状态，许久之后返回504 time out错误提示。
第一反应是：ddos？
ssh登录服务器，正常登入。
排除ddos。
终端输入top，查看资源占用情况，发现java 程序和mysql的CPU占用都很高，尤其是MySql服务，一直居高不下。
推测应该是昨晚上线的功能里，存在某个慢sql或者某个耗时高频的数据库更新操作，多线程下，长期占用cpu，引起了整个系统的雪崩。
登录mysql，用mysql自带功能查看一下存在哪些慢sql。
mysql> show variables like "%slow_query_log%";
+---------------------+-------------------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /usr/local/mysql/data/1055-mysql-slow.log |
+---------------------+-------------------------------------------+
2 rows in set (0.00 sec)(⊙﹏⊙)，当然是默认关闭的慢sql记录日志，手动开启下即可。
mysql> set global slow_query_log=on;
Query OK, 0 rows affected (0.02 sec)mysql> show variables like "%slow_query_log%";
+---------------------+-------------------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /usr/local/mysql/data/1055-mysql-slow.log |
+---------------------+-------------------------------------------+
2 rows in set (0.00 sec)退出mysql，使用vim检查/usr/local/mysql/data/1055-mysql-slow.log文件，即可找到对应的慢sql。
发现慢sql来自于用户页的统一处理，也就是每个点击用户页，都会触发，而用户文章页是整个系统并发最高的页面，每一个点击都会触发这个慢sql。
当即修正对应的慢sql，重新发布上线。
社区服务即恢复。
后续有时间再记录下对于慢sql的优化思路。
