没想到一早上醒来，就看到好几个朋友给发消息问为啥社区访问不了了。

还好今早比往常早醒了半个小时，抓紧时间排查。

输入社区网址，访问一直处于等待状态，许久之后返回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的优化思路。